If you have to do this a lot, you might want to take the time to set up Spacewalk. It will automate creating the repository and populating it with the appropriate packages (or, if you want, all of them). Not to mention everything else it does...
Rpm and deb packages contain archives of the files to install (cpio archives in the case of rpm, tar in the case of deb). These archives contain metadata about each file, including its name, modification date, owning user and group, and permissions. When a package is installed, each file ends up having the ownership described in the archive (unless a post-installation script modifies it).
Most files installed by packages are owned by root, because no user is authorized to modify them.
Alien converts packages by unpacking the archive and repacking it (as well as other things like converting pre/post-installation scripts). For example, to convert an rpm into a deb, alien calls cpio to extract the archive to a temporary location, then tar to build a new archive. If the unpacking is not done with root permissions, then all the temporary files will be owned by the user who is doing the unpacking, so when the files are packed into the new archive, they will end up being owned by that user.
Alien doesn't actually need to run as root since it doesn't need to modify anything in the system. Fakeroot runs alien (or any other command) in an environment where that command receives fake information about filesystem operations, pretending that operations that normally require root (such as changing file ownership) have succeeded. This way, the unpacking is done as root and sets correct file owernship (as far as alien and its subprocesses are concerned) and thus the repacking creates the intended archive.
Best Answer
The problems you've had with alien are most likely not due to a bug or limitation in alien, but to an intrinsic problem of your approach. Converting a deb package into an rpm package is easy, and alien does it well. Converting a package for Ubuntu into a package for CentOS is much more difficult. This means not only repacking the files in a different format, but also moving files around to be in the directories where CentOS expects them, modifying configuration files so that they work on CentOS (e.g. with a different init system), declaring dependencies on packages that have different names (or might not even be present in the distribution at all), etc.
With 500 packages, you're probably going to encounter some difficult cases. Whether it's worth the effort to make dummy packages, create symbolic links and wrapper scripts, tweaking the system configuration, etc. is up to you, but I'd definitely be looking for another solution. In particular, note that there's a good chance that the Debian binariesare compiled against different library versions than what's present in CentOS.
If you want to run programs built for Debian on a CentOS machine, the least effort solution would be to install Debian in a chroot (this guide about installing Debian on another Debian version may be useful, as there's not much dependency on the host side).
If you want to have “proper” CentOS packages then building them from source will be far easier than converting the Debian packages.