Best answer I could get from the bouncycastle.org mailbox:
Yes the scrypt implementation is a real thing - that is to say the code is there, and it passes the official test vectors.
A couple of caveats: the implementation doesn’t exploit all parallelism/optimisations that password crackers will, so there’s a bit of defender/attacker asymmetry. Scrypt is also based on the Salsa20 code function, and Salsa20 performs relatively poorly in Java (on par with AES) while performing awesomely (maybe 4-5x quicker) on platforms with SIMD capabilities.
Scrypt isn’t exposed by the BC JCE provider - perhaps I’d say because the JCE only has very primitive expressions of a cost function for PBE (in the form of an interation count). Scrypt has two cost parameters, so it can’t be trivially forced into that API.
If there’s enough demand I guess it could be exposed through JCE with a hard-coded parallelisation parameter or a BC specific parameter spec.