Qual a diferença entre EJB x CDI?
CDI é a especificação de injeção de dependência e contexto do Java EE. A ideia é que quando você pede um objeto ao controle de CDI, o container vai olhar em um escopo (imagine uma hash table) e, se encontrar um objeto elegível para o ponto de injeção, te devolve um proxy para esse objeto, e não o objeto real. Quando você chama um método nesse proxy, o container pode fazer verificações de segurança, chamar interceptors, decorators e lidar com transações (se aplicável). Depois que tudo isso é feito, o método no objeto “real” é chamado. É assim que acontece a mágica 
EJB é a especificação Enterprise Java Beans, que especifica (obviamente) um conjunto de componentes modulares para utilização em aplicações enterprise. Envolve uma série de fatores, como transações, eventos (aspect oriented programming), a parte do JNDI e, acho que o mais importante, os enterprise beans. Como você já me falou antes que estava estudando, já deve ter se deparado com esses beans. São de dois tipos:
-
Session:
- Stateless
- Stateful
- Singleton
-
Message-Driven
O ciclo de vida desses beans é responsabilidade do container. Cada um tem uma aplicação e um ciclo de vida específico. EJB são também beans CDI. Por isso, você pode utilizar os enterprise beans nas mesmas situações onde CDI é aplicável. Uma “diferença” (não é bem diferença, é um adicional) é que os EJBs do tipo stateless são armazenados em uma espécie de resource pool, já que teoricamente não guardam estado. Isso melhora um pouco o desempenho final.
São duas especificações que estão extremamente relacionadas uma com a outra, e é bem difícil especificar de forma 100% correta a diferença entre elas. Tem como fazer tudo que uma faz com a outra. Acredito que futuramente vai tudo virar uma coisa só! O conceito básico é a ideia do proxy e lookups em contextos.
Apenas um ponto curioso: tanto o CDI quanto o EJB trabalham com injeção de dependências e inversão de controle.
O EJB é uma tecnologia que surgiu há vários anos (desde 1997) como parte da especificação JEE (EJB também é especificação, como o @lvbarbosa disse) e inovou com a implementação de algumas funcionalidades que não estariam atreladas à componentes externos, mas, dependeriam de elementos a serem incluídos no ambiente de execução, (os famosos Servers Application - servidores de aplicação, como JBoss, Glassfish, Oracle Weblogic e IBM Webpshere).
Com o crescimento do EJB (e consequentemente, seus problemas de dependência dos AS), surgiu o Spring Framework (e outros parecidos) que visavam o contrário: entregar o que o EJB fazia, mesmo sem estar em um AS.
Como o Spring cresceu vertifinosamente, houve necessidade de colocar mais coisas na especificação JEE, o que acabou por acelerar a implementação das especificações JPA e JPA 2.x e do próprio CDI.
A especificação JEE (e as que estão abaixo dela, como o EJB, JPA, CDI, JMS, etc) ainda dependem de um application server (embora haja meios de burlar essa necessidade).