In the scenarios you describe, Verisign is the sole Certificate Authority, they have one public/private key pair, and they have one self-signed certificate attesting to that key.
- Their certificate has an attribute on it that identifies it as a valid "issuer", which allows it to be used to sign other certificate requests, but that doesn't make it trusted.
- Being "self-signed" is what makes it a root certificate, but that doesn't make it trusted.
- Verisign went through an approval process to become a trusted certificate issuer, ensuring their practices for issuing certificates are trustworthy; once they did, a copy of their root certificate was placed in the various operating systems and browsers in their "trusted root stores". This is what makes their root certificate trusted.
Let's say Org-1 wants their web site to have a trusted certificate, so they order one from Verisign and install it on their server. The certificate is signed by Verisign, but it is not a root certificate as it's not self-signed.
Org-1's certificate does not have the "issuer" flag on it. That prevents Org-1 from issuing other certificates in the name of Org-2. Verisign does not set the "issuer" flag on certificates it signs for organizations, because that would violate their terms as a trusted issuer.
If Org-1 wishes to issue their own certificates for their own internal use, they must stand up their own Public Key Infrastructure (PKI) to do so, creating their own internal Certificate Authority. They will create their own self-signed root certificate and mark it as an issuer, and they can then distribute it to all of their computers. By placing a copy in each of their computers' trusted root stores, all the certificates they issue internally will be trusted by their computers, but this will not make their internal CA certificate trusted by external organizations.
Note that Org-1 can contract with Verisign (or other vendor) to perform their certificate management functions; but that just means Verisign is operating a private PKI on their behalf. Verisign will create a unique issuing certificate just for Org-1 that is not universally trusted by other organizations; it will have to be distributed by Org-1 and placed in each computer's trusted root store, just as if Org-1 had done it themselves.
This trusted root certificate is the same for all computers in Org-1, but is a different certificate than Verisign's publicly trusted root certificate.
To answer your question 3, because Verisign's certificate is distributed by OS and browser vendors already populated in their trusted root stores, it's already trusted so no, you don't have to have the client do anything extra to trust a certificate signed by Verisign.
Also note that you should not expect external clients to install your internal CA into their trusted root store. That would be an extreme security risk for them. If you need external clients to trust one of your server's certificates, have it signed by an authority they already trust, such as Verisign.
