First of all, to answer your question directly: This cannot be done. It is purposefully not allowed.
You can, in fact write to /dev/random and it will mix your input into the random pool, potentially improving the quality of the output. But it won't update the entropy_count and unlock /dev/random for reading, because that would be cheating. Otherwise you'd be able to do something like this:
cat /dev/urandom > /dev/random # Sup dawg, I heard you like random pools...
Except that you can. Sort of.
There's an ioctl called RNDADDENTROPY available on /dev/random that updates the entropy pool and then increments the entropy_count accordingly. The idea is to allow you to read from a hardware RNG in userspace and dump it into the kernel pool without writing your own driver. Nifty. And while anyone is allowed to dump their entropy into /dev/random (it can't hurt), only root is allowed to use RNDADDENTROPY.
And yes, there is a tool out there that allows you to do this relatively easily; it's called rngd. Its primary purpose is to read from an RNG like /dev/hwrandom or your processor's RDRAND instruction, and constantly re-seed your entropy pool as it gets low. But it takes an arbitrary filename for input, so yes, you can even do this:
rngd -r /dev/urandom
Which, in all honesty, is not entirely unlike doing this:
ln -sf /dev/urandom /dev/random
But as I stated originally, that doesn't mean that you can use this tool to make the kernel use your file as its source of entropy. That bit, at least, is not allowed. You can use it as an additional source of entropy mixed in with all the others, but not the only source of entropy.
If you're convinced your file is of prime-grade randomness, then just use that. You don't have to inject it through the kernel's entropy estimation system. If instead you have a mechanism for generating TRNGs, then by all means dump it in there with all the rest of the entropy sources; rngd makes that pretty simple.
I won't bother telling you about the utter absurdity of religiously avoiding /dev/urandom on real servers, as clearly you've heard that lecture several times and choose not to listen.
But for everyone else, the difference between /dev/random and /dev/urandom only matters immediately at startup on devices without reasonable sources of randomness (like some embedded devices), where the startup conditions are precisely repeatable, and where the random pool is not saved between boots. In all other cases, any theoretical attack against /dev/urandom would require techniques and technology that literally do not exist, and are not expected to ever exist, ever.
From the wording of your question, you seem to be under the impression that /dev/random outputs the result of a TRNG, while /dev/urandom uses a PRNG. This is not accurate. The only difference in output is that random will "lock up" if it's generating bytes faster than it's observing random events, while urandom will not. Otherwise they both run the exact same code on their respective pools. Neither directly outputs the raw bits from a TRNG. Both use random events to constantly re-seed a PRNG.
