According to the Java EE 6 and EJB 3.1 Specification a Stateless Session Bean with the @Singleton Annotation is created once for an Application. If the Application is deployed on multiple VMs (in a Cluster) you have one Instance for each VM.
Of courxe you can have multiple different Singleton Beans.
If the locking and processing of a singleton bean is a problem for application performance, it could make sense to have multiple. But strictly speaking you wont have a real singleton anymore. This would be more like Statefull Session Beans. It is not addressed by the spec, but you could implement it conformant with the Spec by having multiple Singletons (same class, different name). In that case you would have to care for pooling andsynchronizing yourself.
If you talk about the 'standard' Singleton-Pattern (not the @Singleton annotated one).
You might have different Singletons within the same JVM, because it depends to the classloader scope.
Example: you deploy a Singleton-Class in a JAR which is included in different EARs or WARs, in this case it depends to the classloader settings whether you have one or more instances.