We have, on a large project, managed quite well to isolate ArcObjects code from our business logic. That is generally the way to go, I'd say, rather than attempting to mock it all out, even if it is possible using mocking frameworks to get some of the way.
Ask yourself, Why it is you feel the need to mock. Typically, it is because of a missing abstraction. Think small responsibilities and minimize the surface of the huge, ugly ArcObject monster. Avoid dragging around ArcObject types just because some aspect of them is needed somewhere.
I can give one concrete example from our project. A portion of the code seemed to depend on IMxDocument. It turned out the only reason was that the active view needed to be refreshed. So we created an IViewRefresher interface instead and only worked on that; easy to mock and test. Additionally, it makes the intent of the code much clearer and removes the temptation for someone to start doing funny things with the IMxDocument that they weren't supposed to do because all we wanted to do here was refresh. The same exercise can be done with a lot of the ArcObjects code.
Also, we wrapped all access to feature classes in type safe wrappers, again providing mockable code shielding the business code from ArcObjects.
We've discussed not even using the geometry types of ArcObjects, but currently we do allow those interfaces to be used directly in our code. (However, interface knowledge only is allowed and all instantiations of geometries use our own geometry factory.)
In summary, I'm not disencouraging mocking but I'd encourage mocking at a different level of abstraction than ArcObjects.
