"Total amount of memory" is pretty meaningless (for example G1 has 192MB of physical RAM, of which between 90-100MB has been available to the kernel and apps across different releases, but that doesn't include memory used for window buffers and various other things, and each Java application has a limit of 16MB for its heap, so the available RAM to the system is more about how many processes can be running at the same time).
"Amount of free memory" is really really meaningless. We generally try to let as many applications remain running as there is available memory, so between that and normal Linux caches there generally is little no free memory. If you do look at the raw free memory in the kernel, you will see that varying pretty crazily over time as applications start up and use some memory, pushing it down, then other applications get expunged causing it to jump way back up until caches and other things have a chance to gobble it back up.
The best way I have come up at this point to look at the memory state of the system is the "Running services" UI that was introduced in 2.0. Yes, the memory information at the bottom is horribly subtle and meaningless to most people; we should try to figure out how to improve it. :)
You can find out the CPU architecture for NDK code via android.os.Build.CPU_ABI. This gives you a baseline for the CPU architecture, but information like whether the CPU supports NEON instructions or such. For that kind of information, you could conceivably use the NDK to run some native code to interrogate the CPU.