The standard solution for dealing with huge test times (or huge build times) is to run the majority of tests on a separate machine, a dedicated test server (or build server, or CI server), automatically after each checkin into your repository.
Of course, since you still want parts of your tests to be executed immediately when doing TDD, this will only work when you split your tests suit into different testing modules which correspond to the modules of your application. So when you work on a module X, run the subset of tests which correspond to module X locally (and maybe some other tests you always want to be executed). The majority of tests, however, should be executed automatically in the background, and when they fail, the test server (or build server, or CI server) sends you a message or email about the failure.
And yes, this will sacrifice "ultra fast feedback" to some degree, but the feedback should be fast enough for most practical purposes. How well this works depends a lot how well you can structure your test suit into parts which can be executed locally and quickly, and other parts where a certain time lag for the feedback is acceptable.