Yes, this is secure, even though scrypt uses PBKDF2 inside. PBKDF2 has the issue that it the work factor is required $n$ times where $n$ is the number hash outputs concatenated to create the final PBKDF2 output. That means that if you can check the validity of PBKDF2 using only the initial bits (in your case used for the key if the hash was SHA-256, for instance) that you have less of an advantage over an attacker. Basically your initial advantage is divided by $n$.
In scrypt however the final output calculated using a single iteration of PBKDF2, basically turning PBKDF2 into a KBKDF (key based key derivation function) where the calculation of the salt is used as the work factor. As the output size only relies on this single iteration the attacker would not gain an advantage.
That all said, it may make more sense to use a true KBKDF - such as HKDF-expand - to calculate two separate components (key and nonce) from the output of scrypt. In that case the
OtherInfo part of the KBKDF (the derivation data) can be just an ASCII representation of the string
So say that
p = 1 and
MFLen = hLen = dkLen = 32 bytes (output length of SHA-256), then perform:
m = scrypt(Passphrase, Salt, N)
k = HKDF-expand(m, "key", 32)
nonce = HKDF-expand(m, "nonce", 16)
Note that a KBKDF such as HKDF does not contain a work factor; i.e. all the time is still spend in the call to scrypt, not in the calls to HKDF.