1. Well PBKDF is for deriving keys from passwords, you don't need it if your master keys are already safe, just use something like HKDF. (faster)
2. ECDH and DH are certainly the most secure options you have for negotiating session keys. Of course, as you do have a pre-shared master secret you have some interesting new options.
3. Your usage of the HMAC sounds secure. By convention you might want to append the ciphertext to the IV (-> $IV||C$ instead of $C||IV$) as the IV is the $-1.$ block.
4. Your usage of the nonce sounds pretty secure, however you might want to the nonce as associated data to GCM. (not a must-have) As long as you don't reuse nonces for the same key (which you don't do) you're safe.
5. Using seperate keys means to use keys which share no known relation (hashing doesn't count). So you could derive the $K_{MAC}=KDF(MS,"MAC")$ and the $K_{Enc}=KDF(MS,"ENCRYPTION")$, this would be perfectly safe and you wouldn't have to re-perform DH.

Now to solve your session key problem:
It is a non-standard symmetric key-agreement protocol:
Notation:
$r_A,r_B,n_A,n_B$ are all 64-byte random numbers.
$E_K(X)$ notates authenticated encryption of X using a key derived from the pre-shared master secret.

1. $A$ sends $B$ $n_A$. $n_A$ is a nonce, used to guarantee freshness of execution.
2. $B$ responds to $A$ with $E_K(n_A||n_B||r_B)$. $A$ verifies that $n_A$ is correct and saves $r_B$.
3. $A$ finally responds with $E_K(n_B||n_A||r_A)$. $B$ verifies that $n_A$ and $n_B$ are correct.

Now both parties share $r_A$ and $r_B$ and hence one can use these values to generate a session key (without forward secrecy), using a standard KDF.

1. Well PBKDF is for deriving keys from passwords, you don't need it if your master keys are already safe, just use something like HKDF. (faster)
2. ECDH and DH are certainly the most secure options you have for negotiating session keys. Of course, as you do have a pre-shared master secret you have some interesting new options.
3. Your usage of the HMAC sounds secure. By convention you might want to append the ciphertext to the IV (-> $IV||C$ instead of $C||IV$) as the IV is the $-1.$ block.
4. Your usage of the nonce sounds pretty secure. As long as you don't reuse nonces for the same key (which you don't do) you're safe.
5. Using seperate keys means to use keys which share no known relation (hashing doesn't count). So you could derive the $K_{MAC}=KDF(MS,"MAC")$ and the $K_{Enc}=KDF(MS,"ENCRYPTION")$, this would be perfectly safe and you wouldn't have to re-perform DH.

Now to solve your session key problem:
It is a non-standard symmetric key-agreement protocol:
Notation:
$r_A,r_B,n_A,n_B$ are all 64-byte random numbers.
$E_K(X)$ notates authenticated encryption of X using a key derived from the pre-shared master secret.

1. $A$ sends $B$ $n_A$. $n_A$ is a nonce, used to guarantee freshness of execution.
2. $B$ responds to $A$ with $E_K(n_A||n_B||r_B)$. $A$ verifies that $n_A$ is correct and saves $r_B$.
3. $A$ finally responds with $E_K(n_B||n_A||r_A)$. $B$ verifies that $n_A$ and $n_B$ are correct.

Now both parties share $r_A$ and $r_B$ and hence one can use these values to generate a session key (without forward secrecy), using a standard KDF.