I like this use case, as it gives a chance to delineate the sometimes miasmatic space that is "view layout in Magento".
When customizing existing layouts I've found it best to involve as few files as possible. Often it's not necessary to change a template file in order to replace one block with another; ultimately it comes down to the markup.
Let's take the example of the main product template remaining suitable for both situations; you just need to change the media template or the template and its block instance. I would start with a simple layout update handle defined in your local.xml layout file:
<PRODUCT_MEDIA_LARGE>
<!-- if you want same functionality but a different template -->
<action method="setTemplate" block="product.info.media"><tpl>alt/template.phtml</tpl></action>
<!-- EDIT: add skin JS via this handle -->
<action method="addItem" block="head">
<type>skin_js</type>
<file>your/css.js</file>
</action>
<!-- if you want to displace the original media instance & template -->
<reference name="product.info">
<block name="larger.media.block" as="media" type="..." template="..." />
</reference>
<!--
This works using the alias of the media block in the context of its parent.
The original media block instance still exists if you were to need it.
-->
</PRODUCT_MEDIA_LARGE>
Then for each product which should have the alternate template, simply enter this in the layout update field*:
<update handle="PRODUCT_MEDIA_LARGE" />
I like this overall approach for two reasons: your layout logic is defined in one place (DRY), and the instructions to apply it are associated with each entity in the database. Each product page loads an entity-specific handle e.g. PRODUCT_8, but I bristle at using arbitrary auto-increment values outside of the database itself.
NB: I'm pretty sure this will work. I have seen some wonkiness when using update handles in the DB-based layout update context, but this use case should be okay.
