One example that's occasionally used in education and corporate environments is AppLocker, which can restrict application execution to a whitelist based on administrator-defined attributes, including the publisher name from a signature, or the hash of a specific file.
The biggest problem is of course the administration overhead, having to specifically whitelist all programs a user could possibly need. Additionally, many publishers don't sign their applications. And of course it's not a foolproof solution - e.g. a bug in a whitelisted program could still be exploited to run arbitrary code1.
Actually, the executable's signature isn't even the important part. The whitelist can be implemented by path for all the difference it makes - what's important in this scheme is that the user has no write permissions to the program directory2. Assuming that's true, what advantage does verification at execution time provide over verification at install time? No one can change the installed program. If the attack vector is offline editing of files, full disk encryption is the correct answer.
1 Most such bugs would not be considered severe in a normal environment, where they would not lead to privilege escalation. W^X can still be bypassed with ROP.
2 Even verification of signature of the executable will miss external modules (e.g. dynamically-linked libraries) by default. And enabling that can have significant performance impacts.