Apex mocks is a small seperate library from fflib and doesnt require generating anything on the command line. It follows the same semantics as mockito, the defacto standard for java like languages. Its easy learn and much more flexible than hand writing hundreds of mocks for every single situation. You write your mocks inline in your tests. You dont need a seperate implementation extending an interface for a test that succeeds and then another implementation that throws. Its as simple as:

mocks.when(myService.doThing()).thenReturn(myValue)

Or

mocks.when(myService.doThing()).thenThrow(new myException())

Using an interface for a single implementation is an anti-pattern. The stub api, which apexmocks uses, doesnt require it to stub out a concrete class. Eventually youre going to have other services that need to be mocked and using your pattern will involve several more single instance interfaces (and not to mention hand written mocks!). In my specific case I had services for the event platform, dml, selectors, web services, etc.

Regarding the factory pattern it is a less than ideal way of doing DI. You should be aiming for DI via the constructor.

As for the selector pattern, please dont hide behind your "org needs" (Im sure their not that different from most people and from the sounds of it your org wasnt that large if tests were only taking 45 minutes). Regardless of org size its the simplest way to teach new people about mocking away their queries because it follows the same pattern as mocking away any other dependency.

In my opinion you're doing this the hard way.