let me see if i get this right...
As you know, the ejb spec was designed from the ground up to fulfill the commercial holly grail of software engineering - the supermarket of sw components; where an application assembler could go through the shelves filling his cart with the fresh beans of the season grown by ...yep bean providers :) and then hand it (sell it) to organizations where deployers would install the app in an environment given by one of many container providers, and so on ...
In practice, in many organizations (if not most of them...but this is just a gut feeling), a lot of the ejb roles are performed by the same person, wearing different hats, sometimes without even being aware of it.
This separation of roles led to the need to create mechanisms that while isolating the responsibilities of each role, would still allow communication to take place between them. So in this particular case, when you create a bean, you tell the application assembler (and in the case of security metadata, the deployer too, but that's a different matter...) which resources your particular bean uses, without knowing the actual names they will be associated with when the application is actually assembled.
So you, while wearing the enterprise bean programmer's hat, must use "local" names for the external resources your bean uses, whether they are other beans, data-sources, jms destinations, you name it. The application assembler (yep that's you again!) links your references to the actual beans, in the deployment descriptor.
The container ensures that when your bean is instantiated, it has its own jndi environment, where all the resources you declared as references in the dd are available under the tree "java:comp/env" accessible via the Context created with InitialContext() - no params. The spec suggests you use the prefix "ejb" for the ejb references so that an ejb, local or remote, is accessible using "java:comp/env/ejb/<BeanName>" but you don't have to (as your example shows). There is one such "Enterprise Naming Context (ENC)" - refer to the link i sent you - per ejb instance.
For remote beans your bean may act like a standalone application and retrieve remote ejbs through their jndi name in the GLOBAL namespace (which the ejb 3.1 finally standardizes) where they reside associated with the names you provide in the jboss.xml. Local ejbs do not work that way (in glassfish 2.1 for instance they don't even show up in this jndi tree) so you have to access them through the ENC (which you should always do in the first place for the beans that you reference, may them be local or remote - as long as they are in the same jee app).
The definite reference about this subject is chapter 20 "Enterprise Bean Environment" of the ejb 2.1 spec. You may also look into the equivalent chapter 16 of the 3.0 spec.
The link about the jboss stuff also seemed quite exhaustive and although I only skimmed through it would still recommend it.