Some notes:
In software-rendering, poly- and pixel-throughput are precious, so you'll usually have many special-case-optimized polyfillers.
In my renderer I used a "Material" class which creates all required vertex-data from a mesh and contains the polygon-rasterization-code.
The 3D-models (or complete scenes including animation) are usually loaded from files (exported from your favourite 3d-package).
For testing & debugging reasons my "Mesh" class has some static methods to create some simple objects like cube, cylinder, sphere or torus:
Mesh *mesh= Mesh::createTorus(100, 40);Here "Mesh" is one of several object-types (all derived from one base-class) that are stored in a scene-tree (the hierarchical structure might not be required for you yet) and basically contains all information that can be applied by the 3d-software.
To get things rendering, I just need to assign it to a material:
Material *mat= new TextureGouraud(scenetree, Texture("texturefilename") );
mat->addMesh(mesh);
Here "Texture" can either be a bitmap loaded from a file or something procedurally generated (it just needs to derive from the same interface-class).
For rendering I just parse the material-list (stored in the scene-tree) and draw everything that got assigned.
The material has a "transform"-method to put the object where it belongs (multiply vertices by mesh' and camera's matrix) and to create all vertex-attributes; here: calculating rgb-values from vertexnormals and lights (which are also stored in the scene-tree, accessible by the material).
When that's done, polygon's are culled, clipped (each material has a vertex-class with a method for interpolation) and drawn.
For animation, each object has several animation-tracks which store position, rotation, scaling at certain timestamps (and interpolate in between).
"Procedural" animation (like deforming vertices) is job of the "Material", too (since it resambles the vertex-shader part).
Other approaches would just manually updated the mesh' transformation-matrix.
When Hellfire talks about classes he does mean types
True. "Classes" were mentioned a couple of times in the freebasic documentation, but I just realized they don't exist:

This keyword is supported in the latest fbc compiler, however, its usefulness is limited since classes and inheritance are not yet supported.
This is a knockout for most structured design strategies...