No, writing good tests keeps your test isolated and fast. Creating lots of mock objects distracts you from writing good tests, because what you're testing is your ability to 1) write mock objects that conform to the ad hoc interfaces you've produced and 2) maintain those mock objects when those ad hoc interfaces change.
If you want to know if your code works, you still have to test if it all works together.
Personally, I view unit testing differently. I see it as ensuring that my object gets the right data and sends the right messages. If you start adding tests for things like "did it save to the database" or "did it find 3 results" you're now involving your persistence layer with your testing of business logic. It's a tangential concern.
Yes, you still have to write integration tests. But the discipline of testing your objects in isolation and outlining the objects they collaborate with is a major benefit of using test doubles, not a downside. If you can't reason about your objects in isolation, how can you expect to reason about them in aggregate?
I don't use my objects in isolation.
Maybe I can mock up some factory which creates model objects outside of my persistence mechanism, but what value is that? I care that when I create an object in response to an action from a real user the persistence mechanism produces the correct object.
I happily bulk load testing data into my persistence mechanism for testing purposes, but I see almost no reason to mock it for tests.