Those kind of features are intended to be implemented eventually, but will most likely not be in the first release - it will indeed be on a block-by-block basis.
Due to the way Lemmings 3D works, predefined clusters also are not practical for it. First, just as some background info for anyone reading this - L3D does not work on a pixel-perfect basis like L1 or anything resembling that, but rather would be more comparable to the tile-based physics of the NES and GB versions. In terms of the elements relevant to the current discussion, a level is made up of 16384 blocks (32 x 16 x 32).
Lemmings 3D doesn't have tilesets, just texture sets - or more accurately, each level defines its own tileset, using one of about 30 texture sets (almost all styles have more than one texture set corresponding to them - Computer has the most, at 5, while Lemgo and Candy have the least, at one each). Each level has its own individual palette of up to 64 blocks - this palette defines the graphic of each face, as well as some physics properties such as whether the top side is slippery, water, or splat-resistant. (Some features are also controlled simply by the block's index in the palette. Block #0 is always an entrance, block #1 is always an exit, block #2 is always a splitter (or unused). The last special block, as far as I've been able to tell, is block #8, but I only know specifically at this point what #0, #1, #2 and #6 do.) I'll refer to these as the "metablocks", similar to what's done in L3DEdit's source code.
The shape (eg. it could be a slope, or even a corner where two slopes meet) is a property of the individual block instance, not the metablock. An instance of a block can, just like in-game physics, be divided into four vertical slices, though it is not possible to have middle slices missing - within a single block slot, all present slices must be consecutive. On the X and Z axes, the block acts as a single indivisible unit - a basher will only take out the bottom half of a block vertically, but each (equivalent of a) stroke takes out an entire block in the horizontal direction.
So it's quite possible to have predefined shapes made up of blocks, but it's a bit hard to have any reasonable way of predefining the actual blocks that go into it - except on the basis of this purely being a user-driven save / load arrangements feature.
And copy and paste should come first - not the least because saving and re-loading user-defined shapes is essentially just "advanced copy & paste".