It is interesting that the business is more pro-testing than developers! Unit testing adds a tool your development process, but your biggest challenge will be to help your developers through a cultural change. They need to re-define their vision of their jobs to include unit testing.

SkipHuffman touched on this, but I'm going to say it outright. Some things are more suited to automated testing than others. Your co-workers need to have some undeniable unit-testing successes in order to overcome their resistance to writing these tests. If you push them to do it, make sure you push first for something with a nearly guaranteed reward.

For the first pass, I would plan to *NOT* test the database or the UI. Input from a database is difficult to set up appropriately. Tests for UI output tend to be broken when the UI changes colors or other aspects completely irrelevant to your tests.

What I'd call "middleware" is perfect for unit testing. Code that has clearly defined input and output conditions. If you follow the DRY principle (Don't Repeat Yourself), you will have written some little classes or functions to solve recurring problems that are unique to your application.

Unit testing is a great tool to limit the risk of changing existing internal components. Write unit tests before changing an internal component that has worked for a long time, but has a little bug. Test to prove that the currently working functionality is preserved. Then write tests for what you plan to fix and make sure that those tests fail. Fix your bugs. If all tests pass, you are done, and you don't have to manually test all the "downstream" places that the fixed function is used by other code. If you do find a downstream issue, write a new test for that too!

If that works well for you, then you can branch out into other areas. But remember that early unit-testing successes are what you need to bring about the cultural development change that will allow you to continue unit testing!