I've used BDD extensively at many big clients, and seen it used in even more. If your organisation is hesitant about adopting the automation side, you can still focus on having the conversations between testers, developers and business people - this has really helped in a number of places.
At one .NET client we started automating Fitnesse.NET backed by FitSharp, but moved away from it when we realised that everyone who was interested in reading the automated scenarios was technical enough to read code. We were using WPF, so I wrote an automation tool to help us, and mirrored some of the things we were doing in a toy application. You can see the scenarios I wrote here. The way in which I've done this is really similar to what we were doing on the client site. I've also heard good things about SpecFlow, so either way forward should work.
As well as catching the occasional bug, talking through the scenarios really helped us understand what it was we were trying to achieve before we started coding, and we found many edge-cases as a result of the discussions. Every single project I've seen take up BDD has found benefit in it, with the one exception of a project which was only started because the sponsor wanted to use up his budget so he could be sure of getting it again the next year (the transparency around business value in BDD really annoys people who are gaming the system with things like this).
I have also put together a page on BDD which could help anyone who's new to it.
Lastly, you might want to check out Dan North's talk on selling BDD to the business.