This is IMO a lot more than a check constraint. This is a corrective action, whereas a check constraint is a passive restriction. (Actually, this is a lot like the default behaviour of MySQL when it doesn't run in strict mode - accepting invalid dates and coercing it into the '0000-00-00' date, accepting NULL's and converting them to 0 or '' for NOT NULL columns)
To achieve something more like this restrictive behaviour, you can
1) use views with the with check option.
see:
http://arjen-lentz.livejournal.com/49881.html and
http://db4free.blogspot.com/2006/01/emulating-check-constraints-with-views.html.
(BTW, there seems to be a bug in there:
http://bugs.mysql.com/bug.php?id=16813)
2) write a trigger that does the check, and use a 'backdoor' to raise an error. Depending upon your taste, the backdoor can be an UDF (http://dev.mysql.com/doc/refman/5.0/en/adding-functions.html) that always raises an error when you invoke it (http://rpbouman.blogspot.com/2005/11/using-udf-to-raise-errors-from-inside.html), or a call a procedure that violates a unique (or any other) constraint (see:
http://mysql.gilfster.com/page.php?parent_id=2&page_id=2.0.7)
BTW, I feel that the application should check whatever it can, but not for reasons of integrity. You really should not trust the apps to be so nice to check integrity. However, the app should check as much as it can to offer a nice user experience and save communication overhead.