The Salesforce DX CLI can do things at a few different levels. It manages scratch and non-scratch orgs, for example, and it handles deploying and retrieving source. On top of those basic capabilities, it has some tools that handle building specific types of metadata, like
Salesforce DX is a source-based system, and you can always create metadata source code yourself using any tool you please. Convenience commands like the above make it easier, but don't preclude you from simply writing an Apex class and its associated XML metadata to disk and then performing a deployment.
sfdx does not offer commands to programmatically scaffold the metadata for a custom object or add fields to a custom object, as it does for Apex, Visualforce, and Lightning components. However, it's not particularly difficult to generate or template out the XML definitions of that metadata yourself.
The easiest way to figure out what the metadata needs to look like is just to pull some examples from one of your orgs, or you can look through an existing project like those in the
trailheadapps collection on GitHub. Bear in mind that Salesforce has two source code formats (Metadata API and SFDX), so you may see some confusing differences between older and newer projects. You'll start out with SFDX format source code if you're building your project anew with SFDX.
Once you have the metadata in hand, SFDX will happily push it into your scratch org, sandbox, or production org using the
sfdx force:source:push (scratch orgs/source-tracking orgs),
sfdx force:source:deploy (non source-tracking orgs with SFDX source format), and
sfdx force:mdapi:deploy (any org with Metadata API source format) commands.
You can mix-and-match package installations and deployments of metadata from SFDX. Just bear in mind that if you install a managed package you're still subject to the usual limitations on altering managed components.