I think you are looking at this in completely the wrong way. A GUI app and a web page are worlds apart so the exact same definition of MVC will never work for both. MVC is more about the ideal: separating certain parts of the app like display and logic.
In PHP (or the web in general), a View is the web page itself: the HTML output. It's not "live" as per your definition, but you simply click links to go back to the controller (i.e. another page request).
The Controller and Model is where things do differ, like you explained. In PHP the model tends to be the data layer, interacting with the database and so on. But it is still modelling the situation, and the controller still controls the application flow, if only once per page load.
So the name "Model-View-Controller" is perfectly logical, albeit a different implementation in GUI apps vs web apps.
I won't argue with Stephen, even though I could. ;)
Basically, if you want to go with MVC on your own, you'll need at least a request dispatcher and probably a view resolver along with some configuration facilities.
As procedural PHP has no real support for types, coupling problems will probably be a PITA.
In a most basic scenario you could just have a request mapping like
$mapping = array(
"show_profile" => "profile.php:showProfile",
"edit_profile" => "profile.php:editProfile",
"etc" => "whatever.php:doEtc"
);
and then just retrieve the correct setting and explode it to $fileToInclude and $functionToCall. There you'll have your controller-problem sorted out (passing some generalized $request parameter to them or so).
As for a very simple run, your controller could do whatever it should and then explicitly inlcude the view file or return some data so that the view resolver can be invoked with the identifier (e.g. file path or mapping key) of the view to render and the data to display.
There are serveral approaches, and the above one is not even close to an elegant solution (heck, we're talking about procedural code :D) but this is the most simple clean-ish variation I can think of; you can extend on it as you please.
Keep in mind that you want to keep your code as decopuled and maintainable as possible.
(A hard way would be to create a framework with which you could use arbitrary code as controller with arbitrary functions and parameters; the easiest one is simply a matter of some explicit includes)
PS.: I'd suggest using existing frameworks for that matter, but the only publicly available PHP frameworks that are viable are all OO and mixing up OOP with procedural code would be a terrible practice; even worse than reinventing your wheels. Actually, if you don't have to stay procedural at all cost, you better switch to OO.
Good luck with your project!
Best Answer
Like any other utility class/helper function/convenience whatever, where to put it depends on who's using it. If only M uses it, then maybe it belongs in the Model folder. If your M, V and C are all using Dates, then maybe Date belongs in a separate folder from all three. You don't have to put every piece of code in one of those three folders.