It's very rare I can sit down and decide ahead of time what patten to use. Generally my tests and specification's lead me spot a pattern is emerging and refactor to it. This is easily done because of the existing test suite.
To return to your original post:
Now I can and will skip TDD and write in this service but I'm wracking my brains at how TDD can force us into this on it's own which is preferable I think because if TDD drives us our code will probably be optimal.
It's all about discipline. Starting with TDD can be hard, it took me a good while to really get to grips with it.
Ok, so let's say you have your controller depend on the ICategoryRepository contract, FindAll. You know your app won't work because there is no class that implements it, so you need to write it. The test case for this is even because you already know the expected behaviour, it needs to return all the categories. Put together the quickest, dirtiest thing you can to make it pass, and refactor. Remember TDD is a 3 step process, with small feedback loops, Red-Green-Refactor. Never forget the refactor part, this is a core principle.
If your not 100% sure whats next, write a test for the closet you can think of. The point is to define what the behaviour should be right now as you understand it. It might change it 10mins, but you will know your original assumption was incorrect, or needed tweaked. Driving it from your test means you always have that safety net.
Just to repeat: TDD is hard to get your head around. But it's more than worth it, once its clicks, your code will never be the same again. And it will click, it just takes practice and lots of trial and error. I would recommend having a look at some OSS projects and their code/tests. Try applying the styles to your code and see how it goes. Your going to get it wrong before you get it right.