I think there are a couple of things you could do to improve this:
Coupling:
Most of the times composition is preferable to inheritance. Your services are strongly coupled because of that kind of relation. I purpose change it, use composition instead as follow:
public class CompanyService {
private GenericDataAccessService<Company, int> dao; // interface
public void addCompany(Company company) {
dao.save(company);
}
....
}
In order to break the dependency, the dao field should be an abstract class or interface (i don´t know neither your code nor your needs nor java) to allow you inject it.
Testeability:
Injecting these classes' dependencies will also helps you to test your code easily injecting them mock instances.
Unwanted operations:
Using inheritance force you to have operations that probably you don´t want to allow. For example, just imagine you have an AuditingDataService as follow:
public class AuditingService extends GenericDataAccessService<Audit, int>
If you do that, yout AuditingService will inherit a Delete method!!! Can you feel that smell as strong as I do? It will drives you to the following point.
Anti-pattern
In the previous example (delete method for auditing log entries) you will be forced to override it with a do-nothing or throwing-exception method to prevent someone use it... ummmm.... ummm... Can that be a good design?
Conclusion:
I think it is not, simply because inheritance is not well suited here.
Forget for a moment about LoCs and focused on changing the design.
Update:
Java has its own naming conventions and if well Impl is an awful suffix, it is one of those conventions that every java programmer understands and shares. So, I think it is okay.