Wrist-based Pulse Oximeter
There are also implementations, application notes, reference designs, and so forth relevant to FREESCALE, MICROCHIP, ATMEL and others' parts.  I seem to recall Analog Devices had some as well.
http://www.freescale.com/webapp/sps/site/application.jsp?code=APLPOX
http://www.freescale.com/files/32bit/doc/app_note/AN4327.pdf
http://letsmakerobots.com/node/34018
http://www.mouser.com/applications/medical_application_pulseoximeter/
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&amp;nodeId=2723
http://ww1.microchip.com/downloads/en/DeviceDoc/01062b.pdf
http://people.ece.cornell.edu/land/courses/eceprojectsland/STUDENTPROJ/2008to2009/cc464/FINAL_REPORT.pdf

For a watch sized battery powered application, the MSP430 is fairly advantageous since it offers 16 bit processing power, a good free tool set, a well documented reference design, and easily available inexpensive parts.  

For MSP430 &amp; PIC &amp; AVR -- the architecture and peripherals and tool chain are a bit esoteric and unique and would be harder to work with unless you're familiar with them than something based on an ARM CORTEX.  Based on sheer power and ease of design and development tools, you may wish to look at the 32 bit ARM CORTEX MCUS in the low power / small size variety, and there are several in the FREESCALE KINETIS / KINETIS L series, the ST STM32 series, the NXP LPC series, and the TI STELLARIS series that may be worth a look.  

I'd start with getting the nellcor finger (not wrist) probes and trying to implement your application with a combination of an off the shelf development board like the FREESCALE FREEDOM or TOWER units or the STM32Fx DISCOVERY units.  Use a tool like MATLAB/SCILAB/OCTAVE or even EXCEL to process data imported from the unit on the PC, so your first embedded code must do nothing besides simple data acquisition and transferring the data to the PC connected to the development board via serial / USB, SD card, or debug interface.
Once you're acquiring data that results in a good analysis on the PC you can port the signal processing implementation codes to the MCU on the development board and start comparing analysis data from the PC and the MCU.  Once that works you can just design the final PCB and mechanical solution with the MCU of choice in a small enough SON, BGA, or small QFP package to fit your size requirement.   The Cortex M4 units with a FPU could be a little handy since they'll better duplicate the PC based code base's mathematical processing, though using FP libraries on 16 of 32 bit integer processors is quite fine at the cost of speed and code size and needing to understand more about the quantization and range and speed / size limits in the math.  The MCUs with a built in OP-AMP or PGA stage in front of the ADC and with relatively more RAM could help too.
Personally I'd look at the KINETIS parts first and do a competitive analysis with the STM32Fx ones if you find power or size to be a big concern.  If this is for academic / personal research the actual BOM cost issue is irrelevant, though if you were going to make millions of these, you'd probably end up with an 8 or 16 bit MCU for cost reasons or at most maybe a very low end CORTEX-M0 type device.