I installed DD-WRT on my ASUS router... but quickly learned that apparently the CPU on my router just doesn't cut it. Transfer speeds are cut from 20mbps down to only 5mbps. The router I have has a 300mhz CPU... which after a bit of research, turns out that is way too slow for the encryption/decryption necessary with OpenVPN.

So I need recommendations for a decent router. My current ISP plan only allows speeds up to 20mbps... so I was wondering.
What decryption/encryption speeds correspond with a given CPU frequency?

For instance, it can at least be assumed that a 300mhz CPU.... can only really handle about 5mbps based on my own experience. What would 1Ghz accomplish? What about 2 ghz? I also understand that multiple cores don't really benefit OpenVPN, since it doesn't take advantage of multiple cores.

Also, cost is a bit of an issue. A lot of the higher powered routers, it seems are $200... and I just can't justify that cost with my current budget. I would like a router that can accomplish at least 50mbps. I'd be willing to build my own linux-based router, provided I can save money, since I've heard of that as an option.

Mikrotik hEX and hEX S. Specifically has IPsec hardware acceleration. Granted, this is a real standalone router and doesn't have a pretty config but if you've ever messed with enterprise grade routers you'll enjoy the features Router OS employs. It'll run OpenVPN, but there's a special way to do it but good documentation online.

Any PC will run as a router.  I use a qotom like this one: qotom gateway pc

but anything will work for it really.  pfsense, opnsense, untangle, there are tons of unix and linux distros you can use.

I bought a Linksys WRT AC3200 to replace my old POS router.  It has OpenVPN support built in and I've never had a problem with it.  You can keep the stock firmware or use DD-WRT.

disconnect your working theory that encryption throughput is somehow linearly related to processor clock rate; this is not the the case for many, many reasons.

1)
for example, some encryption algorithms are intrinsically less demanding of the CPU.  AES is a good example -- Rijndael was not the "strongest" encryption algorithm in the NIST bake-off for AES, but instead it was the cipher that best balanced strength vs speed vs implementation ease vs cryptographic analysis.  
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard_process
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Performance

2)
another example, some processors have added instructions which are optimized for encryption applications.  an easy example is Intel's AES-NI, which is a feature on some but not all of Intel's processors.  
https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni

3)
another example, some processors (esp. SoC processors typically used in consumer/prosumer/commercial routers) have "hardware assisted encryption".  that is, the encryption/decryption functionality for a small subset of ciphers and hashes (typically only AES and SHA2) is implemented in logic gates.  hence, during decryption an encrypted block of data (example: 256bits = 32bytes) is read into a special memory area by the software running on the processor, and then the software tells the hardware logic to decrypt the block.  a few clock cycles later, typically 4 to 8, the hardware logic has completed decryption of the block and the software can copy the now-plaintext into memory.   compared to doing, for example, software-based AES256 decryption, the hardware assisted approach is thousands of times faster.  in SoC datasheets, you will see the hardware assist called "security engine" or "cryptographic accelerator" or some such.  an example attached below, the Marvell ARMADA XP -- which is an ARM-based SoC used in many NAS boxes -- has such a security engine and can encrypt/decrypt AES256 pretty much at line rate (1GbE) with very little load on the actual CPU since the hardware assist is doing all of the heavy lifting.

4) many other, non-cryptographic aspects affect network performance.  packet size is one in particular; smaller packets result in more overhead and more routing lookup demands.  another is the bandwidth-delay product; in high speed networks high BDP causes problems.

---

so if you want to go fast with encryption/decryption, get the (slow) software out of the way and let (optimized, fast) hardware do it.  
a general purpose CPU is not good at encryption/decryption, but dedicated hardware logic is.

for this reason, to get good performance you need to
a) select a processor or SoC which has onboard hardware assist (that is, a "security engine" or whatever their marketing term is) /// AND ///
b) the software running on the processor/SoC HAS TO BE CONFIGURED TO RECOGNIZE THE PRESENCE OF AND ENABLE THE ASSIST FEATURE /// AND ///
c) the choice of encryption protocol MUST MATCH THE CAPABILITY OF THE HARDWARE ASSIST FEATURE.

so:
- if there is no hardware assist, performance is poor since the SW has to do the encryption/decryption.
- if the software does not use the hardware assist, performance is poor since the SW has to do the encryption/decryption.
- if you use a protocol which is not supported by the hardware assist, performance is poor since the SW has to do the encryption/decryption.

note: IN SOME CASES, using open source software on a store-bought router may result in the inability to use performance-enhancing hardware assist features, because the open source software may have been written to work in the "lowest common denominator" commodity routers.

ar-jedi