N enhances memory consumption with computational enhancement while r simply enhances memory consumption. You further slow your algorithm down with N as compared to R. It's really a matter of preference when you get to very large memory consumption (>1 MB), because at that point you're using RAM and you're going to see a severe slowdown. Additionally, chacha20 should generally be used in place of salsa20 because it's faster and considered exactly as secure.
N becomes a much bigger deal (as far as I can tell) if you use multiple block cipher hash functions because you will be doing many more of these block cipher hashes. if you are using a lot of block cipher hash algorithms (see below) increasing r would be ideal because you may then actually face significant slowdown. see theorem 1 for ROMixH computational time from the scrypt paper.
skein is secure, the reason it wasn't considered for SHA3 was because it's really computationally intensive. the same goes for blake. sha3 (keccak) has extremely high throughput as compared to either of those algorithms (or SHA256, which is similarly slow), hence its selection as sha3.
if you want something that is a total pain in the ass to crack on a parallel machine (asic, gpu) a high N or r value (resulting in 16-256 MB of memory use) and skein/blake for the block cipher will suffice. the more block ciphers you add in tandem (eg SHA256(BLAKE512(SKEIN(data, key))) the worse it gets for asic hashing without strongly affecting runtime performance because need an additional 20,000-50,000 circuits per hash algorithm. but as most of your slowdown is in memory with high N or r values, you can really add as many secondary block ciphers as you like without it making the algorithm a lot slower.
basically all the SHA3 final candidates are reasonably good algorithms, just keccak was the only one that had a ridiculously fast throughput as compared to SHA256. but in this case speed isn't all that important because the size of the data is so small.
the major advantage to using daisy chained block ciphers in scrypt is also that in the event one block cipher is determined insecure, you still have the others as a failsafe. the minor advantage is increased asic difficulty.
if you're interested on working on an implementation like this let me know, i would like to make a block chain based on an algorithm such as this along with some other protocol tweaks for economics.
Here's what I think: perhaps you should consider proposing the next brainwallet algorithm - a problem waiting for an excellent solution and insights like yours.
What you are suggesting here yields the very property that I suggested was desirable, just at the expense of implementation complexity. Thwarting the possibility of ASIC cracking is valuable... but probably so much more so for brainwallets than for passworded private keys meant to be human-readable.
For someone to want to crack a passworded private key, they have to come across one first and hope it was of high value - something I can't imagine would turn into an endeavor that might involve ASICs. On the other hand, the idea of using ASICs to grab at low-hanging brainwallets has a lot of appeal for a potential attacker, since those very well could be high value.
Meanwhile, I wish for BIP 38 to achieve ubiquity, to the point that any merchant could offer the ability to redeem BIP 38-encoded private keys directly on their website, the same way I wish they could redeem unencrypted private keys. Each additional piece of complexity makes it more likely that someone will consider its implementation (or just its code footprint) too burdensome. I feel it's already pushing the envelope by depending on elliptic curve multiplication for what some might perceive as a pet implementation that favors my physical bitcoin products, and it probably is, except for the fact that I don't plan to hold a monopoly on physical bitcoins and hope they too become ubiquitous.
EDIT: it occurred to me that this encryption, as it is, already benefits from requiring a hodgepodge of algorithms beyond scrypt in order to verify that an answer is correct. In order to arrive at the bitcoin address and hence confirm the decryption is successful, one must perform two SHA256's, two rounds of AES, another scrypt with much easier parameters, an elliptic curve multiply... it is not enough to look at just the return values of scrypt.
