You should start by evaluating the problem that you are really wanting to solve. You have a nasty confusing code base that is brittle and filled with technical debt. Often those working on it are required to know the software completely to truly know what other features they could be affecting, however this is unrealistic because the legacy code has gotten so bad over the years that your group has had a revolving door.
There is hope to fix this, but I feel that perhaps commit enforcement of functional tests is like learning to run before you have even started crawling.
1. Refactoring slowly
Learn to get in the good habit of refactoring code as you work on various areas. Perhaps you are fixing a bug in one module, however the code is confusing, scattered, duplicated and doesn't conform to any patterns or designs. This is a good opportunity to take a few extra days to refactor that portion.
Some things to keep in mind when you refactor are to keep an eye on the ideal yet realistic design that you hope to achieve someday. Document your efforts well as you go.
2. Write unit tests for your REFACTORED code
How can you verify that the module or code you have refactored hasn't changed functional behavior? Write unit tests that can verify the newly refactored code. I put emphasis on only writing unit tests for refactored code as unit tests on poor legacy code almost always end up being poor unit tests.
On this note, enforcing each check in to have a unit test will be counter productive as you are wasting time writing unit tests on code that should be refactored anyway, and also it encourages a rushed developer that is close to a deadline to check in incomplete or deficient unit tests.
3. Code review
Get your team in the habit of reviewing each others code and designs. Enforce this procedure for any major code checkin or feature to make sure that code is following proper design, that modules are slowly being refactored, and that unit tests are being added to cover new and refactored code.
4. Automated builds and test suites
Establish and configure automated builds after checkin to verify that code compiles, and also configure that all existing unit tests will run and report any test failures to the team after a checkin. This is a superior means of enforcing code commit quality.
After addressing the following issues, you should begin to start seeing the benefits of Functional Testing in general, however a few of the negatives aspects that I mentioned about commits enforcing the existence of a unit test I feel paint a pretty strong picture that it is not a worthwhile endeavor when you have so much room for improvement of code and feature quality elsewhere in the application.