Not quite - but I have taken a step further in the right direction having previously implemented a mechanism in several desktop applications, whereby in addition to any button or menu item being disabled, a tooltip shows the reason why it is disabled.
Thus we get something like the following (Disabled should be new-lined)

The additional follow through with the F1 highly context sensitive help is an added bonus.
Note that it is important that tooltips are provided everywhere for easier discovery and consistency.
I may well be biased here, but I think this is better than keeping the button enabled because the user is not fooled into thinking that functionality is available, but can still discover why the function is not available and what needs to be done to make it accessible. It helps the user learn about the system and it's requirements, and makes the system seem smarter.
For those with a technical interest, read on:
This mechanism relied on an internal framework called a state manager:
The state manager is a centralized mechanism by which all controls in the application are automatically enabled or disabled by setting and unsetting an internal system state.
Controls affected by the system states are registered with the state manager, along with the system states which affect that control.
System states can be disablers or prerequisites. Any one associated disabler can force a control to be disabled. Additionally, all associated prerequisite states must be satisfied in order for a control to stay enabled.
All system states are described by a message called a reason - i.e. the reason why the state is set or the reason why the state is unset.
When a system state changes, the state manager automatically updates the enabled state of the control, and either inserts or removes the reason from the tooltip (some basic tooltip builder logic required here).
Multiple reasons for disabled state can be combined into the tooltip if necessary.