MVC is a design standard.
Design patterns should be employed to solve a common and standardized "problem", allowing the application of proven solutions and / or standardization of architectures, allowing a team to work in a homogeneous way.
In this way, the MVC design pattern was created to solve the problem of logical organization of a project, using separation by responsibilities, so the Melo is responsible for manipulating data and / or the logical part of the application, (V) iso is responsible for applying all information output logic - it can be a "screen" in html or the generation of XML or JSON responses; (C) the controller is responsible for orchestrating models and views by functionality, it is the one that receives the action requisitions, identifies which models must handle the data for a request, and which views should return the request output / response. p>
It is also possible to apply other design patterns together to solve several "problems" - Front Controller to centralize the requisition treatments, allied to the Dispatcher to identify and instantiate the correct controller to handle a request; DAO / ORM / Active Records to handle persistent data manipulation; Services Layer for agnostic separation of application logic, etc.
So there's a need to apply the concepts correctly.
Regarding your listed questions
The model should handle data, this is the definition, I do not think correct in the model, for example, make the connection with the bank, it is ideal to use dependency injection for this purpose with a class specialized in dealing with the bank's low-level issues.
Creating one template per table probably involves applying the Active Record project pattern. This does not stop you from, for example, having templates that handle session data, such as a Shopping Cart Template, or templates that manipulate collections in arrays. The ideal is that a model has no logic of handling requests or vision.
I'll repeat pretty much the @bigown answer:
The button generates an action / requisition for the controller. This controller will handle the request, being able to validate input data, but not manipulate this data, then pass it to the model (consult, change data etc). After the model (s) manipulate the data, the controller sends the model (s) to a view and it is in charge of generating the output (a screen, a report, an xml, etc). This is the default MVC stream. It just will not generate a vision when you do not have to present anything. You will not only query the model if you do not need any data that is there (remembering that the model may have information beyond the database). Then it is assembled by the set of three things, each doing its part.
In general, these files must be in a public folder for the client (browser) or subfolders of this folder. But exactly how you organize it is at the discretion of a good study of suitability and (taste) yours or your team.
My suggestion would be that you, in addition to studying the concepts of the design pattern, would study and use a consolidated framework that already implements good software architecture using these standards. My list of preferences would be: Laravel, Symphony, Zend Framework; I do not know but are consolidated frameworks with good community: Phalcon, Yii.