Don't introduce root CAs into other organisations
Using self-signed certificates and distributing them through Active Directory is possible, but fairly involved. Esa Jokinen goes into more detail in his answer.
More important are the security implications; root certificates are like a master key, all certificates signed by a root certificate in AD will be trusted by all company computers. If you control a root cert at an application then you can not just create a certificate for yourapp.intranet that will be trusted, you can do that for any domain. Also for bigbank.com, or for google.com.
Essentially, getting someone to install your root certificate puts you in a position to attack all their HTTPS connections. This means you need to have proper procedures for dealing with those keys, for dealing with revocations, and for dealing with security breaches. It also means that those companies need to put an awful lot of trust in you. And I don't think they should, sorry.
Honestly, if a supplier tried to introduce their own root CA into my organization without thoroughly understanding the concerns involved and having proper plans for everything, I would veto them. I'd probably even veto them with those plans.
Depending on the organization, perhaps they already have their own internal CA; in that case you could request a certificate from them; this absolves you from most of these issues, since CA management is their responsibility, not yours. They also will only give you certificates for just your application.
Is there an alternative?
Consider this alternative approach; Obtain a proper domain name for your application, and obtain a regular SSL certificate from any CA. If cost is a concern, there are several parties offering certificates for free. I like Let's Encrypt.
For the domain name, the most obvious options are
yourapp.company.com. The first is easier for you to manage, since obtaining the hostname and the certificate are standardized across all deployments. The latter requires you to deal with the client's IT, but offers better integration for them.
By the way, neither of these options requires your application to be publicly accessible (although that is certainly an option). The domain could simply point to an IP address internal to the company where the application is deployed; You'd need to use email verification or DNS verification to obtain the certificates.
Another option is to have split-DNS; the domain points to a server under your control, which hosts the necessary CA verification stuff so you can obtain certificates. At the company where you application is deployed, their internal DNS points your domain to your private application server.
Replying to some comments
In my opinion, the security zealots blow this topic out of proportion. They treat every situation like online banking, when sometimes all a developer wants is encrypted data transfer.
What you want doesn't exist. You can set up "just encryption", but when you exchange the encryption keys, an attacker can simply intercept those keys and substitute their own, enabling them to read all your encrypted traffic. Certificates ensure that the browser is actually exchanging keys with the intended server, instead of with an attacker. This part is necessary for safe encryption.
In the end, the identity verification is integral to getting the encrypted communication; it is not optional.
The truth is, that a self-signed certificate can provide the same level of encryption (during data transfer) as one used by Bank of America.
Only if you can manage to correctly distribute those certificates. That's easy if it's just one local computer that needs the certificate, but it scales very poorly, and becomes very hard to do right for an arbitrary number of computers.
That's why we use Certificate Authorities; they provide a way to distribute certificates in a scalable and reasonably secure manner.
Apps served from private IP addresses shouldn't have to play by the same rules as international banks, in my opinion.
Thing is, computers don't have common sense. They don't understand that good security is necessary for visiting a bank website, but ehhh security is alright for visiting your app. They can't understand that. And they shouldn't try. What if your app starts dealing with medical records? Suddenly the "common sense" of accepting ehhh security for your app is unacceptable. The computer cannot know that distinction.
If computers have to accept sloppy security on your site, they have to accept it for other sites as well. And luckily we've gotten to the point where that is unacceptable. Accept it, and proudly give your application the same encryption banks use!
It puts a terrible unnecessary burden on the developer
No it doesn't.
Yes, securing a website with HTTPS puts some burden on the developer, such is life. Calling it either terrible or unnecessary is blowing things way out of proportion.
Honestly, just slap some Let's Encrypt certificates on your sites. It gets you the security you want (plus a bit extra), and it's way less effort than complaining about all of this. It's also less effort and safer than trying to be a CA for your clients.