Just creating a test project and writing some test methods is a kind of TDD, but in my experience it isn't much help unless you are working on a library where there is a known API and method calls correspond directly to something expected by the user. You need to come up with the right list of tests, and for a non-trivial application, that can be really hard to do.
I recommend trying SpecFlow - it keeps defining tests nicely separated from the implementation and the structure of the feature files forces you to think about what you are actually testing.
When you define a feature you just write something like
When a user is saved
Then the user should exist
Because you aren't in a code file at this point, you aren't tempted to think about implementation details like which method gets called to create a user or even which class it is implemented in. You can use tags to choose different implementations, so at this level it doesn't matter whether "user is saved" means a call to CreateUser or opening a browser and submitting a form.
Once you have the features defined, all the tests are generated and will start to pass as you implement the step definitions and the actual application code being tested.
For a simple app you can just create the feature files, but for anything more complex it is useful to put together a more complete spec beforehand. I use an iPad mindmapping app for this, but you can use whatever tool you are most comfortable with.
Start with a list of high level features like "User registration". These tend to be too broad to write tests for directly, so break them into subfeatures that can be clearly defined and generally map to a specific user action like "Save user" or "View existing user".
Each of these subfeatures will need a list of scenarios that together completely define whether or not the feature is working, things like "Can save a valid user" and "Cannot save a user with duplicate username".
As you build this list it will generally become clear where the structure needs to be adjusted - if you can't come up with any scenario tests for a feature, or you end up with too many in one feature then that feature is probably defined at the wrong level and needs to be split or changed.