Normally, when HTTPS is done through a proxy, this is done with the CONNECT mechanism: the client talks to the proxy and asks it to provide a bidirectional tunnel for bytes with the target system. In that case, the certificate that the client sees is really from the server, not from the proxy. In that situation, the proxy is kept on the outside of the SSL/TLS session -- it can see that some SSL/TLS is taking place, but it has no access to the encryption keys.
Some organizations implement a full Man-in-the-Middle by generating a fake certificate for the target server on the fly. They do so precisely so that the proxy can see the cleartext data and scan it to conformance to the organization policy (e.g. automatic antivirus scanning). This can work only if the client (your browser) accepts the fake certificate as genuine, which in turn requires that a special organization-controlled root CA is pushed on the client machine (and in a Windows / Active Directory world, a GPO can do that).
About all major vendors for firewall/proxy appliances offer that mechanism as an option.
Not all organizations deploy such a MitM system, for several reasons, including:
Automatic MitM can be expensive. The proxy appliance may have to be computationally powerful if there are many users; and the product license can be high.
MitM breaks certificate-based client authentication.
Doing a MitM makes sense only if you actually inspect the data, which again increases the computational costs.
The automatic pushing of a root CA does not work with BYOD.
As a rule, users really dislike such MitM.