I think it's much more a way of thinking about development, rather than the structure of unit vs. integration testing. To quote from here:
BDD focuses on obtaining a clear
understanding of desired software
behaviour through discussion with
stakeholders. It extends TDD by
writing test cases in a natural
language that non-programmers can
read. Behavior-driven developers use
their native language in combination
with the ubiquitous language of domain
driven design to describe the purpose
and benefit of their code. This allows
the developers to focus on why the
code should be created, rather than
the technical details, and minimizes
translation between the technical
language in which the code is written
and the domain language spoken by the
business, users, stakeholders, project
management, etc.
From the little I've done with it, our BDD focus was on developing a ubiquitous language shared by the business and developers, and writing the tests in a business-comprehensible fashion.