First of all the TDD-way is just gorgeously simple! You write a test first and as soon as the code does not compile (the IDE is a great help here) you start writing production code - but just enough to satisfy the compiler. This way you iterate between test and production code every 30 or so seconds. Then you run the test and see it fail (that's an absolute requirement!). Then you write just enough code for the test to pass and see the test go green.
Stuff always happen. Some times I was just tempted enough to write some production code I knew had no coverage in the test I just wrote (for example damn forced exception handling required in Java - who invented that shit???). So for those parts I've writen separate tests to have all corner-cases covered. That got me to 100% code coverage!
Sure there are some pitiful places like getters and setters that will hold you down but testing them is soooooo easy - you just write a helper method that goes through the properties, sets and gets their value and checks if the property works as expected. It's just like 3 lines of code so one can really afford that to gain the magic 100%
Right now the project is pretty far and let me tell you one thing: changing it is a BREEZE!!! I've probably never worked in a project that I or some else wrote that would be so easy to modify or extend.
The conclusion: Is 100% code coverage hard to achieve? SURE! But we (the professional developers) should still try to achieve it - the peace one gets from it is unbelievable!