Lots of good answers already to this question. I think you need to decide what the word embedded software means to you and/or what you want it to mean. Maybe your definition isnt really embedded. My definition means no operating system. And that will probably upset many embedded software engineers, but the experienced ones like ones that have already answered will certainly understand our variations in definition and why. I think they would call me a microcontroller specialist, and that is certainly true, but I spend most of my time on full speed processors with gobs of memory and rom and I/O, networking, etc. I am the guy that brings the hardware up the first time, flushes out board and chip bugs, then hands it off to what most would call the embedded software engineers. I am an electrical engineer by training and software engineer by trade, so I straddle the line.
It is very possible, and not uncommon that you could remain in the C/C++ embedded world, never have to read a datasheet or schematic, all you would do is call api's that someone else has created. There is a large and increasingly larger market for that as what used to be (my definition of) true embedded, or rtos based embedded (which is often api calls and not the full experience) to this linux embedded thing that has exploded. There is nothing wrong with it, it is fairly close to the experience of developing code for a desktop, but you have to try just a little harder for reliable code since it may be flash/rom based and they may not want to have weekly/monthly updates to units in the field. Ideally never update, but that is also becoming more rare.
The rtos/embedded linux api based embedded is and can still be a different experience than what I call application programming. You may still want or need to read a datasheet or schematic, you may still need to know assembler for the target platform.
I like all of the answers thus far to this question, I guess we are struggling to understand what you are really asking or what you are really looking for in life, add to that what we enjoy about our choices and you get this mix of answers.
I see a few groups, there is certainly the good old true embedded microcontroller stuff, but even that is turning into libraries and apis instead of on the metal, look at the arduino community and stellaris and a bunch of others. I spend a lot of my time in board bring up and test, you have to know a fair amount about the whole system hardware, registers, schematic, etc. Have to know enough assembler both to boot the thing out of reset as well as debug things by staring at disassembly dumps and looking for signs of life in the I/O or on memory busses, etc. If lucky you will get to work on chip design as well and get to watch your instructions execute in simulation. The next group is bootloader/operating system. The hardware working well enough at this point, chip boots, memory appears to work, rom is there. This team writes the production boot code and gets the product from power up into the embedded system, rtos, linux, vxworks, bsd, whatever. this is a talent in and of itself, toolchain, root file system, etc. The next group is the masses, the software engineers that write the applications for that operating system, now some will be reading datasheets, schematics, etc, writing device drivers or apis for others to use, and the highest level may be someone that is all application level programming, the api and sdk calls, some of which may be company developed some may be purchased or other.
Bottom line: Absolutly, there are specialties within embedded. Are you going to know everything? NO, maybe 20 years ago, likely 40 years ago, not today the field is too big and wide. What is the best things you can do for yourself in this field? Learn assembler for a few different instruction sets. The popular ones, arm definitely, thumb version of arm, maybe mips or powerpc or others. If you lean toward microcontrollers, learn (arm, thumb,) avr, pic (blah), msp430, maybe 8051. Read some data sheets, microcontrollers can teach you this even if that is not the field you want, tons of sub $50 development/eval boards (sparkfun.com for example) that give data sheets, simple schematics, assembler, C, etc. If you are a software guy, learn to speak hardware guy, software and hardware folks do not speak the same language, if you can avoid picking sides and stay neutral and speak both languages you will help yourself, your career and whomever you work for and with. Despite any personal views you may have about endians or bit or byte numbering, you are likely to have to deal with some screwy things, and speak to customers/coworkers that can only deal with octal (yeah really) or only deal with the msbit of anything being zero. I recommend looking into verilog and maybe vhdl. At least in a readable sense, not necessarily create it from scratch. If you can already program and know C it is very readable. Depending on the job and the coworkers the verilog and the schematic may be your only documentation you use to write your software. If you cant do it they may replace you with someone who can (rather than get the hardware folks to document their stuff).