Hey 
I don’t follow a strict TDD approach myself, simply because I find that it really gets in the way of my problem solving ability. Instead, when I’m writing new classes, I tend to just blast them out and then revisit them with a unit test pass. Then, for classes that exist and I generally know what I’m doing, I follow TDD. I think TDD is great, I just find that I need to prototype/iterate to figure something out and I haven’t really figured out how to do that with TDD yet.
With that out of the way, I’m just about to release my first game, which is fully unit tested. I tried following a fairly relaxed MVC approach. I did some googling and MVP is pretty similar, so you shouldn’t have too much trouble. I used MSTEST and NSubstitute for my unit testing and mocking.
The way I structured things was to have my objects implement an entity interface, which had Update and Draw. The entities generally handled their own Draw calls but the actual logic of the entities I’d offload to a controller that I would just inject via the constructor, then update during the entity’s Update method. This separation worked really well because I could just write the tests for each piece independently and it all worked out really well.
It’s worth noting that I also wrote tests for all my views. It took me very little effort overall to create, simply making interfaces for the functionality I wanted, then implementing those interfaces as wrappers for the existing MonoGame classes. I posted a topic about this seeing if anybody was interested in this approach. Nobody was 
You can find it here though:
The last thing I’ll say is, regarding the struggle you mentioned, I really wouldn’t worry about finding the perfect solution to MVP. As long as you’re following that general practice, each of your components will be testable and you can achieve your general goal. You can always refactor later and, if you’re sticking to SOLID practices, that should be relatively easy to achieve. Additionally, since you will have written a bunch of unit tests already, that refactor will be extra smooth since you’ll know if you broke something as you go along.
Anyway, to sum this all up, you should definitely be able to achieve your goals here. Just know that not a lot of people actually seem to do this, and that you don’t really need to get hung up on the perfect approach. Your code will evolve and that’s ok. From experience, trying to do everything perfectly the first go around is a great way to get yourself blocked
Good luck!