I think that is a very good goal to aim for. Nevertheless, integration tests have a very important role to play and we cannot neglect them. In my experience those kind of tests are the ones that catch the most of the bugs and also serve as a guide for other to understand how a feature is supposed to work in relation to the rest of the system.
Unit tests suffer from a problem that is very hard to solve, you cannot reliably mock every dependency specific behavior, developers often make assumption about how a dependencies is expected to respond under certain circumstances and fail to model every aspect of it. Databases are the prime example of this.
Stuff like CakeTime, Router and other classes should indeed be interchangeable by mocks in tests and I would love to see that happen. I also subscribe to the idea of separating our tests into two types: unit and integration, but that will mean double work for us... for a big chuck of each unit tested class we will also need an integration test counterpart :P
On CakeTime refactoring, what we need to do is not use the procedural functions but pass around an instance of a DateTime object, which is easy to replace, subclass and mock.