Pronouncable passwords cracking
I am using apg tool to generate my passwords. Unfortunately I've lost my ethereum password. It was generated this way:
apg -a 0 -M NCL -m 16
Here is sample output for that configuration:

Are there any way to recover this password using my mining rig? I have tried this way:
./hashcat64.bin -m 15700 wallet-known -a 3 -1 ?l?u ?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?d
but got error: Integer overflow detected in keyspace of mask: ?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?d
Unfortunately, you can't recover a random password that is that long within a reasonable amount of time.

Just do the math:
?u?l = 26+26 = 52 characters
?d = 10 characters
=> 52 * 52 * 52 * 52 * 52 * 52 * 52 * 52 * 52 * 52 * 52 * 52 * 52 * 52 * 52 * 10 = (52 ^ 15) * 10 =
549604341280186671227207680 password candidates

There would be no way to recover a password with a complexity like this for NTML/MD5 (these are among the fastest hashing algorithms that hashcat supports), let alone for a hashing algorithm as slow as ethereum (the scrypt variant or pbkdf2? It doesn't matter).

Unfortunately, either you have stored the password somewhere or remember at least parts of it, or you should forget about recovering this random extremely long password.

Update: I just noticed that the examples that you listed above do not correspond to the mask that you have specified (my math example was just about the mask you have posted above)
It seems that the character set is actually -2 ?l?u?d ?2?2?2?2?2?2?2?2?2?2?2?2?2?2?2?2
This means, that the keyspace is even worse i.e. (26+26+10) ^ 16 = 47672401706823533450263330816

I think even the fact that you used "pronouncable passwords" (-a 0) doesn't help much (except if there is some really bad weakness of the random output produced by apg -a 0 or the seed that was used to feed the random number generator). Anyway, length 16 will still be infeasible for a slow hashing algorithm like this (ethereum).
So sad to hear that...
No chances? Even with 4 x R9 290 GPU's?
And there could be only one digit in password. And most likely it is last character in password.
Given that these passwords are generated in a semi-random way, with rules around how they are produced to attempt to make them "pronounceable" it may be possible to reduce the keyspace a bit or at least generate markov data based on a large set of these "pronounceable" passwords to increase chances of finding it slightly. That said, still a huge space to be searching, even with any sort of optimizations. If you know any parts or can guess as to what they may have been, you can reduce the keyspace further and try to bring it into feasibility, but its going to be a lot of guessing and luck.