We're changing domains, is it possible to have Sharepoint respond to site.xxxxx.com and site.yyyyy.com with the same content and serve up the correct HTTPS certificates from the same IP?
Yes you have to extend the WebApplication, this will create a new IIS site responding to the new URL, but serving up the same content and then you can assign the proper certificate to that on each web front end server. And you of cause also need to make the DNS point at the same IP.
Yes. You can extend the web application which will create a new IIS site, and you add your HTTPS binding and certificate here. Both "sites" will share the same data. You will need to add Host headers to both bindings in IIS since you are using same port/IP, and validate the alternate access mappings are correct in Central Administration.
SharePoint will update all internal links and relative links correctly, but any hard coded links wont be updated and will direct to the other URL.
Beyond the SharePoint config, if you are migrating users, you will run into issues if their accounts exist in both domains at once (I'm assuming a trust between the domains already exists). SharePoint will treat these accounts as two separate users. There is some work you can do in AD to create what is called a "resource" domain, so one account is the authenticating account, but the other is a data repository. SharePoint is aware of this configuration but I have not seen it used often.
Also when migrating users be sure you are aware that if the "new" user account is not a part of the group, any permissions assigned to the group are not migrated unless the group is also migrated. ( I know you didn't ask about that but I've hit a few times with domain migrations).
SharePoint is able to run a web application (set of content from the content databases) on multiple urls. For each web application you have up to 5 urls that can be directly visible to the user. That is the way microsoft designed the system that is called "Alternate Access Mapping". Each web application requires at least one url in the defautl zone. The url is specified during the creation of the web app. The limit to really only 5 public urls is documented in the KB article 2624320:
In the real world we often used AAM without extending the web application. Using this mechanism it is possible to configure the requested configuration (one web app, one IP and multiple SSL root domains). Due to the fact you have two different root domains (xxxx.com and yyyy.com) you can not use wildcard certificates what is what we normally do to cover more than on SSL site on one IP. If yo stick with one IP and multiple rrot domains for the certificates you can create an SAN certificate (SAN = Subject Alternate Name). Such an certificate can hold various domains andcan so be servered from one IP. This will require you to not follow KB2624320. We only had issues with 401 authentication using claims based authentication (windows kerberos). Running on a classic auth web app (windows kerberos) we never had any issue and we did multiple MS RAP (Risk Assessment Program) without any info about this topic.
The last option is to run on IIS8 and use SNI (Server Name Indication). This technic is working around the issue we all have that the webserver need the certificate to look into the HTTP request to know what host header the client is requesting. Without SNI you need per IP a certificate that allows you to "decrypt" the traffic. Windows Server 2012 (IIS8 = SNI) is supported since SP2 of SharePoint 2010 (http://support.microsoft.com/kb/2724471/en-us)