Am I just not understanding TDD unit testing (Asp.Net MVC project)?

I am trying to figure out how to correctly and efficiently unit test my Asp.net MVC project. When I started on this project I bought the Pro ASP.Net MVC, and with that book I learned about TDD and unit testing. After seeing the examples, and the fact that I work as a software engineer in QA in my current company, I was amazed at how awesome TDD seemed to be. So I started working on my project and went gung ho writing unit tests for my database layer, business layer, and controllers. Everything got a unit test prior to implementation. At first I thought it was awesome, but then things started to go downhill.

Here are the issues I started encountering:

• I ended up writing application code in order to make it possible for unit tests to be performed. I don't mean this in a good way as in my code was broken and I had to fix it so the unit test pass. I mean that abstracting out the database to a mock database is impossible due to the use of linq for data retrieval (using the generic repository pattern).

  The reason is that with linq->sql or linq->entities you can do joins just by doing:

  var objs = select p from _container.Projects select p.Objects;
  

  However, if you mock the database layer out, in order to have that linq pass the unit test you must change the linq to be

  var objs = select p from _container.Projects
         join o in _container.Objects on o.ProjectId equals p.Id
         select o;
  

  Not only does this mean you are changing your application logic just so you can unit test it, but you are making your code less efficient for the sole purpose of testability, and getting rid of a lot of advantages using an ORM has in the first place.

  Furthermore, since a lot of the IDs for my models are database generated, I proved to have to write additional code to handle the non-database tests since IDs were never generated and I had to still handle those cases fo