I'll start by suggesting that you learn the basics of the UI framework you're using (WPF, etc.) before adding an additional framework on top of it. I've seen that this only makes the learning curve steeper.
With that said, the .xaml.cs file is what is commonly referred to as the code behind. This is the code that "controls", so to speak, the UI. You'll note, for example, that these are all "partial" classes because there's going to be some auto-generated code when you compile that does view-specific things like bindings, etc.. The xaml.cs file should be used sparingly and only when you need to know or operate on specifics of the View itself.
With MVVM, you'll often see code behind classes that are almost completely empty, with just a constructor present. The logic in these cases is moved to a "View Model" class which provides a link between the View and the Model (take a look at this SO post for a more thorough description). You should bind to objects in the View Model, and use it as the data context for your view. It contains all the logic to define how the view effects your model.
So - applying this to event handlers... An event must live in the code-behind, because you can't explicitly bind to one in your VM. You could easily call the function you want by accessing the ViewModel right inside that event handler, and there's nothing particularly egregious about this approach. That said, there is another concept called a Command that will live in the View Model itself; a command, as opposed to an event handler, is a Property, so you can bind to that in your .xaml file using
...Command="{Binding FunctionNameHere}"...
It also has nice features like being able to define when the command is valid (so you can disable your button automatically when, for example, the form is missing a required field).
