Litecoin doesn't help. It modified the normal scrypt behavior for inexplicable reasons to use only a very tiny amount of memory compared to the scrypt paper recommendations. It's quite easy to throw 128k of sram on a chip and scream out one cycle/hash. You'd get an even bigger speedup over GPUs and CPUs than you get from Bitcoin.
I'm pretty sure you can't do that. True, you can throw 128k of SRAM on a chip and compute 1 step
of the innnermost Salsa20/8 hash per cycle, but that's not terribly far off what a normal CPU can manage. The problem you'll run into is this key design goal of scrypt (quoting from the scrypt paper):
Conjecture 1. If it is impossible for a circuit to compute the Salsa20/8 core in less than t time, and it is impossible for a circuit to store x bits of data in less than sx area for any x ≥ 0, then it is impossible to compute scrypt(P, S, N, r, p, dkLen) in a circuit with an expected amortized area-time product per password of less than 1024N2r2pst.
What that means is that roughly speaking, no matter what clever scheme you come up with involving pipelining or only storing every Nth value or whatever else you care to try, you shouldn't be able to get a hardware implementation significantly better than if you just threw on a bunch of naive hashing cores with 128k of SRAM each that compute a single Salsa20/8 hash per clock cycle. If you think you could, your scheme almost certainly has a flaw that you haven't spotted yet.