That's what INotifyPropertyChanged is all about. You let the view know to refresh the binding once you you performed your async work.
Button states typically get initialized during VM initialization and may change in response to a user action. Both can be asynchronous. Enabling/Disabling should trigger a NotifyPropertyChanged in the Command so that the view refreshes the binding.
You simply perform your asynchronous query in response to a user action or during VM initialization and once the result comes back you enable/disable the command. You would typically disable all commands in the ctor, so that the user can't click anything until the view model is properly initialized and the appropriate buttons light up.
BTW, why are you using the DelegateCommand instead of Caliburn.Micro actions?
The following VM is somewhat of a good representation of what I'm talking about. Notice how UpdateCommands() is called in the appropriate places after something happens in the application and then UpdateCommands fires NotifyProperty changes on the various CanXXX properties to refresh the binding and have the appropriate buttons light up.
The CanXXX doesn't need to be asynchronous. What matters is that you trigger a NotifyPropertyChanged when necessary, so the view triggers a reevaluation of the appropriate CanXXX properties.