If you add unit tests correctly, and use continuous integration with your repositories, then you MUST keep your tests up-to-date or you cannot push your new commits - you will be blocked from doing so (except for new functionality, of course).
You start with a simple framework and write some very, very basic tests. Then as you work, you refactor the simpler parts of your code so they they have tests. You don't sit down and make adding tests a new project that you work on for months. You gradually, one or two chunks of code at a time, add these in. You build them up over time.
Yes, even this priest issue is something that would be covered by Unit Tests. If you don't think so, you simply don't fully understand what they are. Yes, you will need to do considerable refactoring - which is why you take it in small steps.
I think you should focus on existing code, adding a test each time you fix a bug so that you know your fixes are correct, and so you won't ever have to spend time going back and fixing them again while you are trying to write new code features. However, if after learning about them you think you'd rather start with TDD on your new features, there's nothing wrong with that approach. I would caution against it though - you are most likely going to try to reuse existing code, and since that will be untested and have bugs, I think you'll find you will need to do even more test writing than if you just refactored small things.
What does NOT work, however - as some people have suggested - is to try to have one person who writes test for everyone else. That simply doesn't work. If everyone isn't on board, there's no point bothering.