Is it? Maybe. My opinion would be that it would make for a very poor fit for entertainment software generally, although it might work well for the low level libraries.
EDIT: Here's some justification for my opinion.
Wikipedia defines BDD as a technique that "encourages collaboration between developers, QA and non-technical or business participants in a software project." This already sounds like a bad idea because games differ from most software in that they are not designed as tools to meet a specific need for a 'non-technical or business participant', but are cohesive works broadly designed to entertain. There is an emphasis on "desired software behaviour" but games rarely have 'desired software behaviour' except at the technical level. There is definitely merit in checking that part of the code, but not with the end user, because they will never see it.
But let's assume that you want to throw out that human stakeholder stuff and just use BDD to enforce contracts between different code modules, which as far as I can see doesn't differ much from normal test-driven development, which I also consider poorly-suited to games, for the following reason.
Tests are useful for checking that discrete events happened when expected. This works well in event-driven programming, ie. most of the software world, where an action is performed, some output is generated, and then you just verify that the action and the result match up. However, game software is typically a simulation, where an action does not have a discrete result but a continuous change in the world state. If my hidden player makes a noise, I might want to check that the AI hunts me down. So, I can create a test to make sure that the AI is in 'hunting' state after a noise is created, and that's great. But how do I know the hunting even works? You can't check that instantly - you can only observe it over the passage of time. You can hack in various tests to test certain aspects but this is not well-suited to a typical testing approach.
Additionally, a test-first approach can create a false sense of security, and lead people to believe code is better than it really is.
d = new Dice()
assert(d.roll() between 1 and 6)
Since a test result can give a false positive, you can never escape the basic need to check the code itself. But if the code itself is checked adequately, the test takes on secondary importance. This is why, in my opinion, tests are best used after the event, to test bug fixes.
I wouldn't argue that there's never any benefit in testing that, when objects X and Y work together, the result you get is as expected. The issue is whether you are using the most effective way of verifying this. Methods could include formal verification, a code review, test-first methods, test-last methods, traditional QA black-box testing, or simply using the code as expected and observing the results. The last two options are surprisingly effective most of the time, because despite sounding like they lack rigour, most bugs are found during the course of typical use, and understanding a bug in its natural context can sometimes be easier than understanding it in an artificial test harness. On top of this, formal testing and verification often fails to find problems because (by definition) you can only test for the scenarios you expect - and it's not the expected scenarios that are typically the cause of poor software quality.
So, in summary, I think that test driven development is not necessarily a great choice for software, that tests alone are never sufficient to ensure software quality (and thus the time spent writing them must be compared against alternative uses of that developer time), that games are an especially poor match for automated test cases, and that games are an especially poor match for development methods that look to emphasis 'business value' and 'acceptance testing'.
(Hopefully that is a better answer, even if you don't agree with my points.)