Though your description of the problem does not give a thorough insight into the codebase, I think I can safely say your problem is two-fold.
Learn to write the right tests.
You say you have almost a thousand tests, and you have 120 projects. Assuming that at most half of those projects are test projects, you have 1000 tests to 60 production code projects. That gives you about 16-17 tests pr. project!!!
That is probably the amount of tests that I would have to cover about 1-2 classes in a production system. So unless you only have 1-2 classes in each project (in which case your project structure is too fine grained) your tests are too big, they cover too much ground. You say this is the first project that you are doing TDD properly. A say, the numbers that you present indicate that this is not the case, you are not doing TDD property.
You need to learn to write the right tests, which probably mean that you need to learn how to make the code testable in the first place. If you cannot find the experience inside the team to do that, I would suggest hiring help from the outside, e.g. in form of one or two consultants helping your team over a duration of 2-3 months to learn to write testable code, and small minimal unit tests.
As a comparison, on the .NET project that I am currently working on, we can run roughly about 500 unit tests in less than 10 seconds (and that was not even measured on a high spec machine). If those were your figures, you would not be afraid to run these locally every so often.
Learn to manage the project structure.
You have divided the solution into 120 projects. That is by my standards a staggering amount of projects.
So if it makes sense to actually have that amount of projects (which I have a feeling it doesn't - but your question does not provide enough information to make a qualified judgement of this), you need to divide the projects into smaller components that can be build, versioned, and deployed separately. So when a developer runs unit the test suite, he/she only needs to run the tests relating to component he/she is working on currently. The build server should take care of verifying that everything integrates correctly.
But splitting up a project in multiple components build, versioned, and deployed separately requires in my experience a very mature development team, a team that is more mature than I get the feeling that your team is.
But at any rate, you need to do something about the project structure. Either split the projects into separate components, or start merging projects.
Ask yourself if you really need 120 projects?
p.s. You might want to check out NCrunch. It's a Visual Studio plug-in that runs your test automatically in the background.