Typically the controller is also the place for handling all logic.

The concept "all logic" is quite wide. So I must state I disagree with your statement, as much of the game logic goes into the model. This statement does not help anyone how to implement a MVC pattern.

I can't think of a game where the MVC as a whole is not in real time

As a whole, usually, yes. But, I would argue that the Model isn't real-time. The View will need to know about FPS, and have the responsibility of making sure the player get feed back in real time. And the Controller definitely has real time requirements, even for turned based games (laggy mouse responses can kill any game).

The model will need to know about time, that is usually the case. Especially if it manages physical modelling. But it is enough to have an input function to the Model where it is told the current time, or the delta time since last call. For example, it will be possible to slow a game to slow motion by simply giving a down scaled time to the Model. The Model doesn't need to know that the game is currently in slow motion mode. Thus, the Model should not be concerned about real-time requirements. And the Model should usually not have to care about the CPU power.

Of course, there are complications depending on what type of game it is. The model must not use too much CPU, or the View and Controller may no longer fulfill the requirements. Some games, like chess, may have a complicated relation to time. That is, the model is allowed to use a limited real time to find the next move. But even in that case, I would delegate the real-time responsibility to outside of the Model.

typically the toggling between 1st/3rd Person Perspectives would also be stored as model data.

I disagree again. This is a typical example where the Model should not be involved. However, the Model will need to support the View with information needed to show data in both 1:st person and 3:rd person, but the Model shall not know, or care, whether the game is currently in any of these specific modes. There are always exceptions, of course.

• There can be only one: no need to isolate different instances. On the other hand, game entities, like the individual enemies, could be objects (other sensible options exist).
• There are no alternative implementations of a common interface; you are simply ripping out of GameMaster a part of the game logic that deals with enemies. Meaningful interfaces with (at least potentially) different implementation often include the "brains" of game entities (AI, user input and replay systems could control the exact same unit) or rendering (once you know what you need to draw, you can draw it in different ways).

You're all doing it wrong.

Design patterns and architectures are descriptions of how problems can be solved. They emphatically are not prescriptions of how to solve those problems in all future cases.

As soon as you start thinking of "the" design for some software, you have failed as a designer, architect, and engineer. There is no "the one right design" - ever. Even after you are done with your code, there is only "how I did it" versus "many other ways it could have been done."

Do not fall into the trap of exclusively and blindly using design habits, principles, patterns, guidelines, suggestions, recommendations, or anything else. Do not reach for some off-the-shelf solution to every design problem.

Use your brain and think about how best to solve the unique problem you are currently facing. Otherwise, you're not doing your job. Being lazy with your solutions will bite you eventually. Resist the urge to get stuck in a design rut.

In short: your question is broken. Un-ask it.

I'm not saying there's no value in studying other people's solutions; I'm saying that just lifting someone else's approach wholesale into an arbitrary new project is a recipe for disaster.