Someone could do this, but it's not going to fit in with the Debian project's security goals. There's no way they'd accept random people as builders for an official Debian distribution.
How does this sound for an algorithm for a build-related program that would ensure trustworthiness of built packages (built on random volunteer's machines)?
Let's assume the following is realistic:
An appeal to "give back to Debian" is made on the front page of raspberrypi.org, by donating, or self-hosting a dedicated Raspberry Pi build machine. Since a Raspberry Pi, a cheap SD card, and an ethernet cable costs about $60 (about half of the price of the cheapest Windows 7 Home Premium license), a few hundred tech-savvy volunteers step forward. They effectively pledge to set up a dedicated, headless, Debian build machine, allowing remote SSH login (and they already know how to set up port forwarding through their NAT broadband routers). After all, since most Ubuntu users know that Ubuntu is based on Debian, they know that when they "give back" to Debian, they are also, in turn, giving back to Ubuntu.
Granted the above is realistic, here's what the new trustworthiness-ensuring build-related program would do:
What if there were some kind of a trusted "master builder" machine, which knows all the available volunteer build machines to log into (and ports, in case they're not port 22), perhaps being stored in Debian's build machine database. Then for a given package to be built, it randomly chooses 2 build machines, not being on the same subnet whatsoever, then initiates build processes on both build machines, and waits for the resulting built packages to be returned. Once both built packages return, they are compared, by calculating an sha1 checksum on both. If they match, then the built packages are trusted. If they don't match, then one of those two build machines is suspicious, to say the least. One of the two packages is not trustworthy, and perhaps has some added evil hackery. So the "master builder" machine asks yet a third randomly-chosen build machine to build the package a third time (again, being on an entirely different subnet from the first two machines). Then the third built package is checksummed as a tie-breaker. Whichever machine was the "odd man out" gets a "strike" against it, and the suspicious package gets put into a quarantine folder for forensic investigation later, if desired. After three "strikes" from any build machine, it's de-listed from the possible pool of build machines.