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.
I have been working on Spring projects of various size, fromtiny microservices (sometimes less than 100 lines of production code) till big monoliths (with 20+ full time developers working on single codebase).
First of all, my experience is that monoliths tend to be often over-complicated and full of accumulated accidental complexity. Therefore if you feel that your team is experiencing inefficiency caused by bloated codebase, you should consider splitting it into more autonomous and separately manageable components. It doesn't matter if you are using Spring.
Secondly, maybe you encountered Functional Programming movement that is taking over mainly alpha geek community. One of the fundamental ideas of Functional Programming is strict separation of code and data. Actually functional programmers believe strongly that it is terrible idea to combine data (state) with code into objects as it is done often in object oriented programming.
I personally also believe that encapsulating state into bunch of objects and defining logic on these objects to mutate this state will create huge mess in monolithic applications. No matter how great developers you have on the project, they will create codebase that is hard to maintain, as state mutations issues are often very tricky to reproduce and discover.
In that regard, Spring default singleton scope actually makes codebase much easier, because you should always strive for not defining any state on singleton beans. Think about them as a code only, where all of them are strictly stateless.
State in your application represents scalability problem, because if you have stateful application you can't have various instances of it. So state should always be handled carefully in caches or storages dedicated to storing state (e.g. distributed caches or data grids or databases).
Now to the first bullet point, do not try to inject non-Spring beans into Spring singleton beans. I work with Spring 5+ years and I can remember only one case where I used Prototype scope. Just create your DTOs via constructor and do not mix them with Spring context. It is wise idea to keep these DTOs as dumm as possible. That means use create only getters/setters/toString and hashcode/equals for them if needed. I highly recommend using Lombok project for generating these boilerplate methods, so that your DTOs are very readable.
To the point about a lot of parameters passing around. Just group these parameters into higher level DTO. E.g. if you are passing around parameters: customerName, customerId, customerCreditCardNumber, just create DTO Customer and pass that around. Easy enough. If don't want to pass around anything, just use Request scope to bind state to the current request. All the beans can autowire this Request scope bean and mutate its state. But this should be very rare and exceptional case as it may hide tricky behavior often. It's equivalent of global variable for request. Bad idea generally.
To the second bullet point. I believe it was covered already with my other points.
I know that these approaches are significantly deviating from what we've learnt on the college when OOP was the preferred approach. But industry slowly starting to realize that it wasn't right approach for writing complex web applications. I highly recommend looking into functional programming principles as they seem to be the future.
Best Answer
Your code specifically implementing MVC pattern then No but is it actually MVC, well that answer is YES.
As Bart van Ingen Schenau points out the data as well as behavior to retrieve the appropriate data are encompassed by the model. This is correct but the important thing to remember about JSF is that the framework itself is inherently MVC.
JSF Model
The managed bean and Spring injected business logic encapsulates the model.
JSF View
Your XHTML markup represents the View components. This markup also contains Controller hooks that bind your Model (Managed Beans, ORM entities, etc...) to the View components.
JSF Controller
This is just FacesServlet. It is the controller that creates the interaction between View and Model so that the web developer doesn't need to worry about this.