Welcome to the game industry :)
So you're doing a massive refactoring. Massive refactoring is Evil, but that's not the topic. You were probably given this task to test your nerves anyway, so don't give up on it.
My answer is: you have to break it down into little chunks. It'll be your daily routine in a few months, so you have to learn how to divide and conquer. It's basically your job. A few suggestions:
Make sure you understand what this component is supposed to do. Play with what you have to take out and see what it does, ask your colleagues if your assumptions are right.
You're rewriting this module for a reason. It might not be obvious to you, but if you were given this task it's most likely because something was so crappy that people feel it's better starting it over. Ask around: what are those defects?
Try finding the core feature of the component you're rewriting, its very substance, the reason it exists, and start by getting this one working. It must be really tiny, as small as you can. Ask your colleagues about what they think this feature would be. If it's a GFX system, just make it display one polygon. If it's an animation system, just place one bone properly. If it's an AI system, just make it play an animation. Etc. etc. Just trash everything that gets in the way and gives you all those daunting errors. Don't get disturbed by the details, just get this core feature working as quickly as you can. Your implementation will be ugly, full of bugs and hacks and magic numbers and you wouldn't let anyone glance at your code, but that's not a problem.
Once you've got this core feature, you'll already start feeling better. It's essential to see the result of your work as early as possible 1) for your morale 2) to be able to test it. So, test it, stress test it, torture it. If it crashes or shows some really bad bug, fix this. It's the heart of your module so rework it a bit and clean it up until you feel comfortable with it.
Then show it to your colleagues and ask them if that's what the game needs. Ask for a code review: your colleagues will probably tell you about plenty of things that you didn't think of. You'll have to refactor again to make sure your implementation fits with what the rest of the team wants.
Then when you feel ready for it, pick one of the other features you trashed earlier on, rinse, repeat. Make it work as fast as you can, rework, ask for a review, re-rework.
I have to put the emphasis one last time on this: communicate. Ask you colleagues, not only your lead, not only the programmers, everybody that will use or test or evaluate this system. Don't fear about asking stupid questions: when in doubt, it's always better to get the information right now than to wait weeks for a meeting or a review.
The reality of game programming is that you're not going to create brand shiny new systems everyday, it's a job of keeping focus and getting the things done quickly and efficiently. Pull yourself together, get to work, and good luck!
There's extra info I find useful in Leo's comment and dhasenan's answer, I'm shamelessly steeling that from them to complete this answer.
I didn't write about how to deal with inter-dependencies. The module you're rewriting is probably deeply coupled with the rest of the game, that's why you get so many errors when changing something. So there's two solutions:
If there are just a few dependencies, then you're lucky. The old and the new module can be kept in parallel for a while, you can even have a switch for your users so they can decide to change between the old and the new module whenever they need to. Just put a switch somewhere, in a configuration file or in a debug menu, and use it where-ever your module is plugged to the rest of the game. When your new module is ready for production, put the switch on by default. Later on, when the old module is not used anymore or when production needs to go on, remove the old module and the switch.
If there are many dependencies, you have to unplug and re-plug them one by one. Try to keep both modules in the background, and each time you get a new feature to work, switch to the new module for that feature. I.e. unplug and re-plug what's related to this feature. It'll take you some time because it's probably more work than changing just one function call: some data structures might change, the program flow might change, etc. But it's still better than rewriting everything once and taking weeks to kill the compilation beast. If that's really impossible to keep both the old and the new modules in parallel because you module is so vital to the game, you might consider rewriting in place. But beware that this could mean that if the defects are in the old module's interface, you'll end up with the same defects. Anyway, if this happens, try taking advantage of this refactoring: you might be able to remove a few dependencies or to split the module in sub-modules for the sake of good software design.
If there's something specific to video game development, it's this: we're not doing rocket science, or a complicated research work, we're part of a creative process. When doing something, you have to craft a first version as quickly as possible so it can be tested, played, frown upon, and modified. You can't spend weeks doing "one very long piece of work" without delivering a bit.