Main purpose for Carmichael's Function in RSA
You're have everything basically right.  Modern RSA-based cryptosystems, as in PKCS#1, do indeed use the Carmichael function.  Usually we pick $e = 3$ or $e = 2^{16} + 1$, try a different modulus if $e$ divides $\lambda(n)$, and otherwise use $d \equiv e^{-1} \pmod{\lambda(n)}$.

I'm not sure how you conclude that the extended Euclidean algorithm is not utilized—usually that is how we compute $d$.  The EEA, given $e$ and $\lambda(n)$, computes coefficients $c$ and $d$ satisfying Bézout's identity $c\lambda(n) + d e = \gcd(e, \lambda(n)) = 1$, meaning that $d e \equiv 1 \pmod{\lambda(n)}$, or $d \equiv e^{-1} \pmod{\lambda(n)}$.  Of course, we require $\gcd(e, \lambda(n)) = 1$ or else $e$ doesn't have an inverse modulo $\lambda(n)$ or $\phi(n)$ at all.

You can use $e &gt; \lambda(n)$ or $d &gt; \lambda(n)$, but it's no different from using $e \bmod \lambda(n)$ and $d \bmod \lambda(n)$, so there's no sense in wasting space for a larger number except in exotic applications.  You can also pick $e$ at random, but it offers no security and only hurts performance: roughly, the Hamming weight of $e$ determines the number of multiplications modulo $n$ to compute the public key operation, and $\lfloor\log_2 e\rfloor$ determines the number of squarings modulo $n$ needed to compute it.  (Certain exponents may also admit more efficient Lucas chains than the naive square-and-multiply algorithm.)

You want to minimize these because they make up the bulk of the public key operations.  Using the fastest option $e = 3$ is perfectly fine for sane RSA-based cryptosystems like RSA-KEM and RSA-FDH signature, and even the standard and fairly widely used RSAES-OAEP and RSASSA-PSS, but people are terrified of $e = 3$ because there are some ways to use RSA stupidly that enable, e.g., decryption or forgery by computing real number cube roots, so $e = 2^{16} + 1$ is a more popular choice.  $e = 2$ brings you into the territory of Rabin cryptosystems, which are qualitatively a little different, but have a neat reduction to factorization.

(If you pick $d$ small to speed up the private key operation instead of picking $e$ small to speed up the public key operation, you expose yourself to Wiener's attack.)