Be cautious. You must also ensure that the default comment does not become a crutch. For example, you should validate that the defect number is valid (currently open, for example, as well as actually exists). Otherwise, the programmers will simply use the default comment as the only comment.
In my view, it would be better to put the effort into validating the comment than into providing a default. Tell the developers that their changes will be rejected unless the comments meet the requirements - and document what is expected (and accepted).
The questioner challenges "nicely said, but does not answer the question".
Fair enough. I don't really use CVS, so take what follows with a pinch of salt.
Looking at Karl Fogel's book "Open Source Development with CVS" (Coriolis, 1999), I don't see a good way to do it. There are 'commitinfo', 'loginfo' and 'verifymsg' files that all seem to specify programs that validate log messages, and the editor is launched when the user doesn't specify 'cvs ci -m"Why I committed this"' (or, 'cvs ci -F why' for a message in a file), but personally I always checkin with comments on the command line and would hate to have an editor launched for me. So, short of writing a wrapper for the cvs command (which would be moderately complex), I don't see a way in the book of doing what you request.
Hmmm...unless you override the user's definition of CVSEDITOR in a shell script wrapper for cvs with a program that creates the default message in the given file and then launches ${VISUAL:-${EDITOR:-vim}} instead. Ick, and likewise yuck! But, done carefully, it would work. Probably the hardest part is ensuring that the programmers use your script version of cvs instead of the binary.