PBKDF2 can produce output of arbitrary length. With HMAC/SHA-512 it does so in 512-bit chunks, but it is not restricted to 512 bits. If you need more bits then you can have more.
If you want to use the same password for authentication and for encryption, then the proper way is to "isolate" them from each other. I suggest the following: for the user password and salt (salt is on the server, and sent back when any client asks for it), the client computes PBKDF2 and obtains at least 256 bits. The first 128 bits will be used for authentication; the other 128 bits for encryption. Presumably, knowing the first half of the PBKDF2 yields no clue about the second half, and vice versa, except if the source password is guessed through exhaustive search (we are expecting PBKDF2 to behave like a Pseudorandom Function Family, the salt selecting the function in the PRF).
For authentication, use SRP indeed. For encryption, use GCM or EAX. GCM and EAX are nice encryption modes for AES (or other block ciphers, but primarily AES) which handle both symmetric encryption and a MAC, and can do so with relaxed requirements on the IV: these modes just need a non-repeating IV, not necessarily a random IV. You don't have to derive the IV from the password, and indeed you should not do it in case you want to encrypt several files with the same password, because then all the files will get the same IV, which is known to be a problem. Just encode the IV (counter, random... whatever floats your boat, depending on the encryption mode) in the file header.
It is not scientifically needed to use more than 128 bits for encryption or for authentication. Some people find psychological comfort in having huge keys, though.
It shall be noted that since the client first requires the salt from the server, an attacker impersonating the server could feed the client with a fake salt. Forcing the client to use a specific salt might allow for precomputations (aka "rainbow tables"). However, the SRP protocol ends with a pair of verification messages which validate that "everything went well" (when using SRP with TLS, the TLS Finished
messages play that role). In the envisioned case, these messages not only guarantee to the client that it talked to the expected server, but also that the salt value was the right one, not one provided by an attacker.