All your business rules (and application) should be in the model layer of your application. The controller should just be collecting (from models to views) and sending (from URL requests to models) the data.
Your models can be composed in two layers, the business logic (and application) and your data access layer. Your data access layer execute queries (SQL, NoSQL, Web Service or even text files).
Your models should not be "aware" of the type of storage you are using. This way, you can change and combine different data access mecanism (your users are in a database and the rest of the data comes from a web service for example).
To cleanly integrate your data access layer in your models you should rely on dependency injection
You've got a lot of moving parts in your question, touching on a lot of concepts, but here's my basic advice when it comes to how to think about a mid-to-large scale MVC application:
Presentation <---> Business Logic <---> Data Access
Firstly, it's best to not think of the the app as "an MVC application". It's an application that uses the MVC pattern as its presentation component. Thinking about it this way will help you separate out your business logic concerns from your presentation concerns. Perhaps it's ok for small applications to pile everything down to database access into the MVC structure, but it'll quickly become untenable for a mid-to-large application.
MVC (Presentation)
In your app, the ASP.NET MVC component should deal with transforming business data for display purposes (Models), displaying the user interface (Views), and communication issues such as routing, authentication, authorization, request validation, response handling, and the like (Controllers). If you have code that does something else, then it doesn't belong in the MVC component.
Repository/ORM (Data Access)
Also in your app, the data access layer should be concerned with retrieving and storing persistent data. Commonly that's in the form of a relational database, but there are many other ways data can be persisted. If you have code that isn't reading or storing persistent data, then it doesn't belong in the data layer. I shared my thoughts on the ORM/Repository discussion previously on SO, but to recap, I don't consider an ORM to be the same thing as a Repository, for several reasons.
Business Logic
So now you have your presentation layer (MVC), and your data layer (repository or ORM) ... Everything else is your business logic layer (BLL). All of your code that decides which data to retrieve, or performs complicated calculations, or makes business decisions, should be here. I usually organize my business logic in the form of 'services', which my presentation layer can call upon to do the work requested. All of my domain models exist here.
Your Approach
This is where your approach breaks down a little for me. You describe your MVC controller as the place you would get data from the repository, and call upon the MPGCalculator to do some work, etc. I would not have my controller do any of this, but instead would delegate all of this off to a service in the BLL.
In other words, I would not inject a repository and MPGCalculator into the controller, that's giving the controller too much responsibility (it's already handling all of the controller stuff I mentioned above). Instead, I would have a service in the BLL handle all of that, and pass the results back to the controller. The controller can then transform the results to the correct model, and pass that on to the correct view. The controller doesn't have any business logic in it, and the only things injected into the controller would be the appropriate BLL services.
Doing it this way means your business logic (for example, given a set of vehicles, calculate the MPG and sort best to worst) is independent from presentation and persistence concerns. It'll usually be in a library that doesn't know or care about the data persistence strategy nor the presentation strategy.
Best Answer
One issue with these discussions is the all-to-frequent mixing of different architectural viewpoints in the same discussion or diagram.
Mixing both viewpoints (depth and breadth) together in the same diagram tends to lead to confusion. In surveying the sources your citing, I find no shortage of this kind of mixing of these what would more ideally be separated architectural viewpoints.
For example, the diagram you're showing (citing Microsoft), you have said MS claims to be an MVC diagram, but it is primarily showing depth in the domain model, with overweight focus on persistence (from the MVC perspective). So, this diagram is weak on the breadth viewpoint of interacting peers (M,V,C) and mixes in some depth viewpoints with persistence: broken out (and elevated to be a peer of the other components). It is understandable that one might question where the domain-logic belongs given the-all-to-easy-to-mix architectural viewpoints.
In MVC, the model is what is responsible for maintaining domain objects, responding to domain-oriented queries & commands (including validation, etc..), and enforcing/effecting domain-oriented rules & behaviors. MVC doesn't speak to breaking out persistence: if your system includes persistence that is an implementation detail (detail of depth, not of breadth). Thus, there is no question as to where domain-logic belongs in MVC, or whether domain-objects should be dumb or smart — these questions are all internal aspects (implementation details) of the model.
You are also correct that the term Model is overloaded and over used. So, what the term means has to be evaluated in some context. Unfortunately, many of these discussions fail to set or keep context, adding to confusion.
In MVC, the term Model means what I mentioned above (keeper of domain objects, handler of queries & commands..). We might speak of POJO's, and such discussion should apply to the interactions between the peers M,V,C, and whether the query & command interface to the model uses dumber or smarter objects.
In detailing persistence — an implementation detail from the MVC perspective — we can speak to POJO's, or smart/dumb at different places in the persistence mechanism, we can even reuse the term model at different interfaces in the implementation details of persistence.
In summary, it is possible for the term model to be used in both ways you're describing — it is not either/or. What makes things confusing is that we often fail to set context, and/or fail to show when we're shifting context from breadth (interacting of peer components) to depth (implementation detail of usually of one of these component).