To me a service class is about implementing a use case, so I name it according to what kind of user the service is acting on behalf of. So if I have an application with different roles, say Customers, Order Fullfillment people, Data entry people, and Admins, then I'd likely have a CustomerService, an OrderFulfillmentService, a DataEntryService, and an AdminService. I think naming a service according to the kind of data being fetched or twiddled is an anti-pattern. So guessing that UserAccount manipulation would be the domain of an Administrator I would probably call it "AdminService".
