It is generally a good idea to wrap business logic into services. Often, such services methods uses doctrine’s repositories to operate on data storage. Injecting whole EntityManager service is very popular approach, but it isn’t the most elegant way I could think of. EntityManager works only as a factory in that case and could lead to usage of other repositories, which might end up with too many responsibilities of given service.
The better way, is to inject single repositories, using factory-service mechanizm, provided by Dependency Injection Container.

Services.xml configuratio consist of repository declaration and bespoken service:

Below we have an implementation of our custom entity repository. It doesn’t do anything special at this moment, but is prepared to be developed in the future.

The last but not least our service, which will make use of injected repository.

One more thing: I suggest to type hint to EntityRepository, because it will be ready to provide default repository (not your own). This also decouples service from repository implementation, which is good thing in terms of Dependency Inversion principle.

UPDATE 2013-10-15
After receiving very useful feedback in comments below, I have something to add. It’s better to have repository which implements your own interface, but this interface should extend ObjectRepository interface from Doctrine\Common\Persistence namespace. With this approach repository’s contract (custom methods) are specified in interface and this interface also denotes ObjectRepository behaviours (as it extends this interface). Moreover, this repository extends EntityRepository, which gives it all needed things to interact with query builder and entity manager. One disadvantage is that, the interface is coupled with Doctrine Persistance, but it’s okay in this case.