First off, in a modern desktop application, there are better patterns than MVC for separating the user interface from the application logic. For example the MVVM pattern. The problem is that the MVC pattern expects a strict separation between the View (what is presented to the user) and the Controller (input from the user into the application), but most GUI frameworks don't support that strict separation.
In the MVC pattern, the Model part is everything of the application that does not directly deal with user-interaction. In the original formulation of the MVC pattern, which you seem to refer to in your question, the View part is the code that draws the dialog on the screen and the Controller part is the part that handles keypresses and mouse clicks.
The View has read-only access to the Model part, so it can retrieve the information it needs from the Model. In your example, the Controller would receive the name entered in the search field and the press on the "Search" button. The Controller would then tell the View to update the displayed list of users to include only the users with the provided name (or starting with that name if it is a prefix search).
To expand the example with notifications from the Model, suppose that somehow a user gets added to the database (or removed, or has their name changed, etc.). The Model would send a notification to the observers that something has changed in the list of users. As the View gets that notification, it retrieves the list of users again according to the current filter criteria and updates what gets shown.
In the MVVM (Model-View-ViewModel) pattern, which is related to the MVC pattern, the Model is again everything that doesn't deal with user interaction. Here, the View does all the user interaction, both display of content and receiving keypresses/mouse actions. This can be covered for a very large part by the Window and Widget objects (and subclasses) of a typical GUI toolkit. The ViewModel is in part a glue layer between the Model and View parts, transforming data as needed, and in part a model of view-specific data items, like the current selection in a list.
In the MVVM pattern, the interaction in your example would be that the View informs the ViewModel that the filter criteria for the user list have changed and what name to filter on now. The ViewModel then retrieves the list of users from the Model and applies the filter (or possibly, asks the Model to provide a filtered list). Then the ViewModel tells the View that the list of users to show has changed and the View retrieves the filtered list to show it.
If the Model changes externally, the ViewModel can be notified of that change via the Observer pattern and the ViewModel can retrieve the new (filtered) list and inform the View to update what gets show.
