Well first off, the split should not be between commands and events, but rather between domain and read models. You can't really map CQRS commands to CRUD operations as a general rule, although most of the commands in your system will change the state of your repositories. I will give you a general overview of how this works. Say you want to add a user, you create a command AddUserCommand and assign an id to that message. On the back end, you have an handler for that command and you're right that the command does not return nothing. Once that command is handled you should publish and event reflecting the change: UserWasAddedEvent. The id of this message will be unique, but it can and should have an id related to the command which you created in the UI. Your read models should handle the event and update a read model with the command status (waiting, processing, completedOnError, completedSuccessfully) depending on the event you published. On the UI after you submited the command, you should start querying the read models whith the ID of the command you created to get the status and then update your UI accordigly.
Your right that CQRS handlers return void, but you should bear in mind that typically in an architecture like this, the backend should return the validation results of the submited commands, not the handler itself but the infrastucture around your cqrs handlers.