Do the figures specify the presentation/application/data logics? If
They don't specify them in any precise sense, but they do show a high level logical organization of the system. Presentation logic would be a part of the user-facing tiers (desktop GUIs, web pages, mobile device screens). Most of the application logic would be in what's on both pictures marked as "Tier 2".
"Tier" is a somewhat overloaded word, and people mean slightly different things by it, but these tiers may be just the logical organization of the source code, or how the code is packaged into libraries (e.g., DLLs), or they could represent different physical machines. My impression is that "tier" most often means "physical tier".
In real systems, things may not be organized so neatly. E.g., some of the application logic may need to be moved, or even duplicated on the user-facing tiers, to provide better user experience. Sometimes, parts of it may end up in the database tier, for various practical reasons (both good ones and bad ones).
Do the figures specify the presentation logic exactly as "user view"
and "control" (in both two tier and three tier cases)?
Again, nothing is specified precisely here, but yes - presentation is concerned with displaying information and user interface, and this is what we call "Views". "Controls" here most likely refers to just the things that the user can do with the application, or it may even literally refer to GUI controls (buttons, textboxes, checkboxes, menus, things like that).
Do the figures specify the application logic exactly as "data
manipulation" and "Application" (in the two tier case)?
Roughly, yes. One way to think about this as application logic being separated by concerns of the two tiers (e.g. the fine-grained logic that can be done on, say, a phone, vs the more coarse-grained, resource-intensive logic that executes on some backend service).
I'll repeat the image here for easy reference:
The idea with having separate notions of presentation and application logic is that your application logic (the thing that your application actually does) shouldn't depend on the way stuff is being shown to the user (the presentation logic), and on the intricacies of how exactly it's done. The image here is not really designed to show that; it's more focused on the high level organizational view of the system.
Do the figures specify the data logic exactly as "data management" (in
the two-tier case) and "database manager" (in the three-tier case)?
Yes; it just means that there's some kind of a database that stores the data and provides various capabilities that let you query it, etc. But, depending on the application, it could be something as simple as a file, and some code that governs how you read and write to it.
Do the figures specify the components of the MVC framework? If yes,
No. There's no notion of MVC in these pictures.
Do the figures specify "V" in MVC exactly as "user view" (in both two
tier and three tier cases)?
If MVC was shown here, the V would roughly correspond to "Views and Controls"
Do the figures specify "C" in MVC exactly as "control" (in both two
tier and three tier cases)?
No. Here "controls" most likely just refers to either the on-screen widgets (buttons and such), or just the things that the user can do (in the same sense you'd use the word "controls" in a video game). In MVC, C stands for "Controller", which is a component that sort of coordinates the interaction between the Views and the Model (see below).
Do the figures specify "M" in MVC exactly as "data manipulation" and
"Application" (in the two tier case), and "data management" (in the
two-tier case) and "database manager" (in the three-tier case)?
Not quite. The M in MVC is not about data storage. MVC is a GUI pattern, so it's concerned with the GUI and the presentation logic. In MVC, you can think of the Model as of a black box of sorts that encompass "the rest of the application"; from the presentation-related point of view, we don't really care (and we want to be isolated) from the internals of the rest of the application - we just want to know how to interact with it. A more useful way to think about it, though, is that the Model corresponds, on a very conceptual level, to the application logic, or to a part of the application logic that's relevant for this particular view; in contrast, the layered/tiered view is a high-level overview of the application as a whole.
That said, there's a lot of history and a lot of terminology here, and there are different variants of MVC itself, and related patterns like MVP, MVVM, etc. You'll encounter terms like "ViewModel" and "Presentation Model" - this is not the same as (or related to) Model (if anything, they are associated with the Controller, or Presenter in MVP). Then there's Web MVC where Views correspond to web pages (as in, HTML/CSS/JS source), or templates that generate such pages, rather then desktop widgets. There too you may encounter "view models", but these are often just data bags that serve as a way to pass data to the view, so again, it's a different notion.
Also, the original MVC (when first invented/described) was different than how we think of it today - back then, every little widget had it's own trio of MVC components (as in, every button would have its own View that could draw it, a Controller that knew how to deal with user input, and a little piece of application logic that was represented by its Model). That's not how we use the pattern today; typically, a View would be an entire screen, or maybe a panel within that screen.
How do the presentation/application/data logics and MVC correspond to each other?
Since MVC is a GUI pattern (some might call it GUI architecture, but it doesn't really matter), most of it is about the presentation layer, and the organization within it.
Does the presentation logic exactly consist of "V" and "C" in MVC?
I'd say that's roughly correct; at least, V & C are concerned with the presentation logic (but as C also interacts with the Model, one might say that it handles additional concerns as well).