It's fine, as others have noted.
However, by invoking PBKDF2 twice (first to check the password, then to derive the actual key), you're essentially doubling a legitimate user's workload, whereas an attacker still only needs to run it once for each guessed password. Thus, you're cutting the legitimate user's advantage in half, or, equivalently, wasting one bit of password entropy.
(Also, the way PBKDF2 is defined, deriving more than one hash output length of key material is basically equivalent to invoking the whole PBKDF2 function two or more times, so you won't gain much that way. Other KDFs like scrypt may behave differently in this respect.)
Instead, I would recommend deriving a single "intermediate key" $K_I$ from the password $P$, using PBKDF2 with a suitably high iteration count, and then deriving both the password verification value $V$ and the actual encryption key $K_E$ from the intermediate key using a fast KDF (e.g. PBKDF2 with an iteration count of 1), like this:
$$\begin{aligned}
K_I &= \text{PBKDF2}(P,S,c,\max(\ell_P,\ell_V,\ell_{K_E})) \\
V \,\|\, K_E &= \text{PBKDF2}(K_I,S,1,\ell_V+\ell_{K_E})
\end{aligned}$$
where $S$ is the salt, $c$ is the iteration count, $\ell_P$ is the output length (in bytes) of the PRF used to instantiate PBKDF2, and $\ell_V$ and $\ell_{K_E}$ are the desired byte lengths of the verification token $V$ and the encryption key $K_E$ respectively, and $\|$ denotes their concatenation.
(The reason for choosing the intermediate key length as $\max(\ell_P,\ell_V,\ell_{K_E})$ is that we want the intermediate key to be at least as long as each of the final outputs $V$ and $K_E$, and there's no point in asking for output shorter than what the PRF naturally gives us; in fact, an even better choice could be $\max(\ell_V,\ell_{K_E})$ rounded up to the next multiple of $\ell_P$.)