Does each microcontroller line have its own programming language/syntax?

The language in this case is exactly the same. The Arduino environment happens to have some extra libraries (just more C code) that 'wrap' the access to the actual hardware registers (DDRx, PORTx, INx, etc.) with slightly more user-friendly functions. This increases the overhead (more instructions need to be executed for the same operation) but increases flexibility as it is "simple" to write a program that uses only these calls, then retarget it for a different chip (say, an arduino mega) and the library will handle the proper mapping internally.

There aren't really any 'standard' APIs for really low-level access across chips from different vendors. However, all of the low-level access is done in the same way - reads and writes to fixed memory addresses - so the overall access method will be similar between different parts, just the details and names will be different. Perhaps one will just provide header files with huge lists of #defines register addresses cast to pointers. Or perhaps the header files will use structures to keep things organized with a bit of a hierarchy. Some manufacturers may also provide higher-level APIs. This can be very useful for peripherals which are complex and difficult to configure. GPIO is very simple, but something like a USB controller with DMA support could have hundreds of registers. Generally API documentation will be provided with the vendor-supplied toolchain.

So the bottom line is yes, you will need to learn some new register names, but the language is still C++ (or C, assembly, or perhaps something more esoteric).

You are confusing microcontrollers and compilers. The high level languages you can program any particular micro in is a function of what compilers are available for that micro.

At the low level, the micro executes machine instructions, which a compiler derives for the text file you give it that you consider to be the "program". You are really specifying some logic to perform, and the compiler figures out how to use the available machine instructions to implement that logic. In this case, what you program in is a function of the compiler, not the micro's native instruction set.

You can program a micro by specifying native instructions directly. This is done by using assembly language. Like a compiler, the assembler is a translator that takes a text file you write and produces machine instructions as a result. The difference is that in this case you are specifying those machine instructions directly. Each instruction is given a name, and you write these names instead of the binary opcodes, but you are still specifying the instructions directly. The assembler only does the grunt work of figuring out the exact binary encoding of each instruction from the name and options you write in the text file.

While a high level language can be the same across very different micros, the machine instructions are usually only similar within a family of related micros. For example, all the Microchip PIC 18 have the same instruction set (mostly), which is different from the basic PIC 16, and different again from the 16 bit parts like the PIC 24 and dsPIC 30 and 33.

Microprocessors and Microcontrollers will typically use a shared architecture between different product and manufacturer lines. These architectures typically define a low level command set (instruction set) common to all implementations. A C or C++ compiler will be able to generate bytecode executable on all e.g. ARM processors.

However, the architecture is only half the picture. Since there are lots of specific memory addresses, on board peripherals, memory management and other implementation details that the architecture doesn't address

A manufacturer or third party will typically provide a collection of source files (an HDK) that will provide definitions, port mappings, and example code. Typically the HDK is for C and C++. Typically the HDK will have a demonstration board associated with it (think $500 arduino). A lot of detailed configuration work is often necessary to adjust the development/sample platform to the device you are designing

The Arduino is based on the AVR architecture and is primarily supported by Atmel. Arduino has created a platform bootloader and a library of simplified C++ functions and objects for you to use the platform with minimal effort. The Arduino platform and IDE is designed for hobbyists with minimal equipment. Before the arduino, the PIC fulfilled a similar role with an easy to use and cheap BASIC environment.

In a professional environment typically this support is provided by the vendor/manufacturer or is contracted out to a third party. They provide the low level code and headers and you write your application with that HDK, in larger organizations this could be done in house. There is a recent trend for manufacturers to build an open API/Software ecosystem around their platform that makes them as easy to use right out of the box as the arduino. There are still countless chips with very little programming support, and most platform knowledge locked away in the corporate world.