Rather than "bypass" encryption, they can spoof the identity of the server, so as to perform a MITM attack (effectively).
Encryption itself is only one part of the configuration when setting up an SSL/TLS connection: this ensures the confidentiality of the communication between the client and the server. Before that, the client needs to verify the identity of the server, to make sure it's exchanging data confidentially with the party it expects: this is what certificates are used for.
An X.509 certificate is issued by a CA for a given server name. If the browser trusts this CA (there are a number of trust anchors provided by default with most browsers), it can trust its content: the binding between its public key and the name it contains. The browser also has to check that the server name it was looking for is one of the names in the certificate.
What the government can do is to ask you to trust its CA certificate (and/or have the big CAs give them an intermediate CA certificate) so that they can issue certificates for their surveillance device, thereby spoofing the real server certificate. This device would be a server and decipher the connection and then act as a client itself to the real server: you would then have 2 encrypted sections: one between the client and the surveillance device, and one between that device and the real server.
There exist appliances that do this (sometimes referred to as "MITM proxy servers"), typically used on a enterprise network.
Besides the fact that anyone in control of that CA's private key could see and alter any traffic the client makes to an HTTPS site (there are a number of non-technical problems here), there are a number of technical problems when doing this at the scale of a country:
These proxy servers may need to be explicitly configured in the browser (as an HTTP proxy).
Indeed, it's quite difficult to implement a MITM proxy transparently, because it can't always get the name it should put in the certificate it generates dynamically by just looking at the initial TCP packets. If Server Name Indication is not used (SNI is quite common nowadays, but not supported by all clients), all it can get is the IP address of the server, which may not necessarily resolve back to the expected name. For example, if you get the address for www.facebook.com and do a reverse DNS lookup, you'll get something like www-XYZ-XYZ.facebook.com. It could work with a wildcard here, but that pattern can't be expected in general.
This will make any service that uses client-certificate authentication break. Since during the SSL/TLS handshake, when a client certificate is used, the client signs the concatenation of all the handshake messages (including the server certificate) at the end, and the server compares it to what it has sent and received (including the real certificate). If there's something in the middle that inserts it own certificate, this is going to make this verification fail.
There will certainly be a delay in the establishment of the handshake, since the certificates may have to be generated dynamically. (Some could be cached.)
This expects users to "play nice" and use the ports that they are meant to do. Alternative ports might not be monitored or would have to be completely firewalled.
To track down Facebook/Google+/Gmail exchanges in a usable form, these devices will also need to be able to look through the structure of the pages (or JSON payload for AJAX) and be able to extract the relevant data (or to store everything it can't understand somewhere). Any slight change in the internal API of those services would require some costly adaptation.
Doing all this for all HTTPS communications will certainly require a large amount of computing power and yield a substantial electricity bill.
(It's possible that the reports that led the Home Office to make such plans were drafted before Facebook switched to HTTPS for everything, by the way.)