Even though I haven't been in a TDD or BDD project, or I have been in some that say they are doing TDD but are pretty far from it, these are things that I think about and really try to read as much as I can about.
Back to the question. When you're doing BDD you should write your "test" first and make it fail, right? And then implement that feature or what you call it. But if you take this to the extreme couldn't this be some kind of top-down development? You're looking at your UI and says, "I would like to have this feature/behavior here". Then you fix your UI to implement that feature and the code that supports the UI. At this point you haven't implemented any business logic or data access logic, you have just implemented your behavior. What I'm aiming at instead of writing the test first you write your UI code first. In some cases it should result in the same code for the data access and business layer, since you use your UI code to define what your business needs to support.
Of course you should complement this with tests that is used to make sure that the feature is working as it should in the feature.
UPDATE: Good answers and thoughts from everyone I think. Some of you have stated, in one way or another, that you need to write your test first otherwise it is development-driven. I definitely agree with that when talking about TDD, since your test should drive your development. But when talking about BDD I'm not as sure that you have to write your test first, isn't BDD all about defining your behavior first? I think that looking at the UI and say: "hey I want this behavior/functionality here", sound quite behavior-driven to me. I don't say you should skip all your test but you could use the top-down approach as the first step as defining your behavior. I do think that when you have taken that first step and maybe implemented the feature in the UI with some mockup data you should start defining your test that verifies that behavior.