You'll need a time machine that can go back to the AES selection process to ask for a larger block size than 128 bits and/or faster key schedule. 96 bit nonce i

You'll need a time machine that can go back to the AES selection process to ask for a larger block size than 128 bits and/or faster key schedule. 96 bit nonce is so short because in counter mode you encrypt 128-bit block representing the nonce+counter and XOR the result with the message. In IETF/NIST standards, the block is split into 96 bits of nonce and 32 bits of counter, thus with one nonce you can generate up to 2^32 blocks of key stream without repeating it. Some other standards split 128-bits into 64-bit nonce and 64-bit counter. As you can see, there's not much you can do to make it larger. Salsa20/ChaCha is built with a 512-bit permutation (with initial word additions at the end to make it into PRF), which processes 256-bit key, 128-bit nonce+block counter and 128-bit constant. Similar situation here: we can split 128-bit nonce/counter into 64-bit nonce and 64-bit block counter (original DJB version) or 96-bit nonce and 32-bit block counter (IETF version, used in TLS). However, since there's no key schedule — key bytes are directly fed into the permutation, it's not expensive to change key for each message, unlike with AES that has to run key schedule for every key change. This neat property is what allows XSalsa20 (Salsa20 with 192-bit "expanded" nonce), to be quite inexpensive: basically it "hashes" 128 bits of the expanded nonce and original key with the same permutation, truncating it, into a new key, and then uses this new key along with the other 64 bits of the expanded nonce with Salsa20.