+1 for people's recommendation of SpecFlow for scenarios; never used it but heard many good things about it. I've been using plain old NUnit with a little DSL like this. MSTest would work similarly.
You can also do BDD in the unit space, which is what MSpec is designed to do. I'm personally hating MSpec, but the rest of the team here love it. They like writing examples of how the code works. I like to show why the behavior is valuable. It's a subtle distinction and if you're not worried about doing this at a unit level it won't hit you.
Other frameworks to look at include Concordion, Fitnesse.NET (please put FitSharp behind it!) and TickSpec.
In the real world, the most valuable bit of BDD by a long way is the conversations, not the automated tests. Here's a couple of quick hints and tips for making it work:
Don't write automated tests over things which are in flux. It just commits you to stuff you got wrong. Wait until the UI has settled a bit then do it.
If you don't care much about your UI, but do care about data integrity, write the scenarios over the controller / presenter layer (eg: for admin screens).
Don't start with login. Start by describing a valuable part of the application for which you might log in. Do that first (assume you only have one user). You'll get quicker feedback on the risky bits.
Seek quick feedback on the risky bits, which will usually be the bits which you've never done before. Use scenarios to have conversations around them. Write anything interesting you discover down, but forget the scenarios which are obvious - they're obvious! Don't worry about automating them to start with. Having conversations is more important than writing down conversations is more important than automating conversations.
Good luck! If you want to know more about BDD, I put together a page of relevant links here.
