At what stage is DHE and RSA used during the SSL/TLS handshake? At what stage of the SSL/TLS handshake is the DHE and RSA used and what is the purpose of using a pre-master secret when you could just use RSA to exchange the symmetric key (i.e. AES) for further communications. I am confused how DHE, AES and RSA fuse into the SSL/TLS handshake process. Is there a handshake with purely RSA, purely DHE or both.
The SSL/TLS handshake consists of a series of messages which do keyexchange and (usually) authentication together. See rfc5246 or its predecessors or Wikipedia for details. 
The handshake actually results in one "premaster secret" and one "master secret" 
which is then used to derive multiple keys: 
an encryption key for each direction (for an algorithm that may be AES or something else), an IV for each direction for suites that need it (which is all CBC suites in protocol versions before TLSv1.1, and some of the AEAD suites in TLSv1.2), and a HMAC key for each direction for suites that need it 
(which is everything except the AEAD suites in TLSv1.2).
See How key materials are generated in SSL V3 from master secret
and What is the purpose of four different secrets shared by client and server in SSL/TLS? .

The original, and still a common, keyexchange method is RSA, sometimes emphasized as 'plain' RSA or kRSA. The server sends a certificate containing an RSA (public)key; the client validates 
the cert and uses the publickey to RSA encrypt the random premaster secret. 
The server proves correct decryption (and is implicitly authenticated) with the Finished message. 
The server can optionally request client authentication; if so the client 
sends its own cert and uses its matching privatekey to sign a partial transcript, which the server validates and verifies, but this is rarely used. Except possibly the client auth, this is 'pure' RSA.

DHE (DH in ephemeral mode) is used in conjunction with a signing certificate, which can be either RSA or DSA. 
The server sends its cert which client validates, and also its DH group and ephemeral publickey signed under its cert; client generates its ephemeral key in the same group 
and sends that, plus its cert and signature if client authentication is used.

There is also a method to use DH keyagreement without certificates and authentication, which is in effect ephemeral, but SSL/TLS doesn't call it that, it calls it DH-anon instead. This is usually a bad idea; many people imagine only passive eavesdroppers 
and think they only need encryption, but in today's internet active attacks of many kinds are widespread and if you don't use authentication you probably aren't secure.
You could view this as 'pure' DHE even though it isn't called that.

There are elliptic-curve variants ECDHE (ephemeral, RSA or ECDSA signing} and ECDH-anon. 
The handshake sequence, and security properties, are the same, only 
the actual crypto computations are different. These are technically optional 
but in fact nowadays widely implemented and becoming more popular to use. 

And there are 'static' methods (DH and ECDH, no E or anon) which use 
long-term [EC]DH keys instead of ephemeral ones. This requires certs for 
the static keys (and preagreement on the group or curve) which is less 
convenient, especially for classic (non-elliptic) DH, although TLSv1.3 is planned to add standardized DH groups that might change this, and these methods don't seem to be used at all on the public net.

Finally, there are some methods that don't use publickeys at all, including 
Pre-Shared Key (PSK) and Secure Remote Password (SRP). These basically work only in 
a private net (or virtual one) and aren't seen on the public net.

AES or other data cipher like 3DES or RC4 is not used in the handshake. 
It is used for data after the handshake.

Contrary to @mirabilos for [EC]DHE methods the ephemeral key material IS 
signed under the server cert and the client cert if client auth used. 
Not for the -anon methods, which are designed not to authenticate.