Good time to be moving; the 8-bits are dying rapidly; when you can buy a $5 board with (for example) an STM32F103 which is a rather capable 32-bit ARM microcontroller (with USB even!), there's no doubt times have changed.
You've had some excellent answers already but primarily I'd say "forget assembly" and almost "forget caring about how the cpu works at a low level" - one day there'll be a corner case where you need to dig into it (a specific optimization or for debugging) but ARM cores run C code exceptionally well (by design) and you vary rarely need to venture deep inside the guts.
This does mean you'll spend a certain amount of time banging your head against issues with compilers (and especially linkers and makefiles) barfing obscure errors at you but they're all surmountable.
The guts of how the ARMs work (i.e. the ARM cpu books) are dense and not very interesting until such day as you actually need to optimize (and you'll be amazed how infrequently that is when you have 32 bit registers and your PLL'd CPU clock is in the region of 100mhz).
The "old skool" ARM instruction set is much easier to read a disassembly of than the much newer "Thumb2" - which is what you find on most modern microcontroller-level ARMs (Cortex) - but again the innards of the assembly-language instructions mostly fade into the background; if you have the right toolset (especially a decent source-level debugger with breakpoints/single step etc) you just don't care too much about it being ARM at all.
Once you're in the world of 32-bit registers and 32-bit data bus widths and everything you ever wanted available on-chip you'll never want to go back to an 8-bit CPU again; basically there's often no penalty for "taking it easy" and writing code to be legible more than efficient.
However... peripherals... aye and THERE'S the rub.
You sure do get a ton of stuff to play with on modern MCUs, and a lot of it is pretty fancy stuff; you often find a world of sophistication far, far beyond AVR, PIC and 8051 on-chip peripherals.
One programmable timer? Nah, have eight! DMA? How about 12 channels with programmable priority and burst mode and chained mode and auto-reload and.. and.. and...
I2C? I2S? Dozens of pin muxing options? Fifteen different ways to reprogram the on-chip flash? Sure!
It often feels like you've gone from famine to feast with the peripherals and it's common that there's whole chunks of a chip you'll admire but barely use (hence; clock gating).
The amount of on-chip hardware (and variations on that in just one vendor's line of chips) is nowadays fairly mind-boggling. One chip vendor will of course tend to re-use IP blocks so once you get familiar with a certain brand it gets easier but "shit done got craaaazy nowadays."
If anything the peripherals and their interactions (and DMA and interrupts and bus allocation and and and...) are SO complex (and, on occasion, not exactly as described in the datasheets) that engineers frequently have a favorite range of ARM MCUs and tend to want to stick with it simply because they're familiar with the peripherals and development tools.
Good libraries and development tools (i.e. fast compile+debug cycle with a proper debugger) and a large set of working example code projects are absolutely crucial to your ARM MCU choice nowadays. It seems most vendors now have exceedingly cheap evaluation boards (
As I'm sure you've noticed, once you get beyond the microcontroller level with ARMs and into the SOC level (e.g. Raspberry Pi/etc style SOCs) then the rules change completely and it's all about which sort of Linux you're going to run, because - with vanishingly few exceptions - you'd be barking mad to attempt anything else.
Basically; regardless of the CPU that (may) have been pre-selected for you on this gig, buy yourself a handful of super-cheap Cortex-based evaluation boards from a few different vendors (TI, STM, Freescale and more come to mind) and have a hack around with the provided sample code.
Final piece of advice; once you find the page-or-three in the datasheet that describes the pin-muxing options for the exact part number chip you're working with, you might want to print it out and stick it on the wall. Finding out late in a project that a certain combination of peripherals is impossible because of pin muxing is no fun, and sometimes that info is so buried away you'd swear they're trying to hide it :-)