Maven commands are built using two types of instructions, namely 'plugin goals' and 'build lifecycle phases'.
Every Maven plugin implements several goals that can be executed in isolation or along with other goals. Maven goals are invoked writing the plugin name and the goal name separated by a colon and eventually followed by a list of property pairs, for example the following command will invoke the 'create' goal on the 'archetype' plugin, creating a new webapp Maven project:

Check here for more info about the archetype plugin:
http://maven.apache.org/plugins/maven-archetype-plugin/index.html
Another plugin usage example, creating an eclipse project:
mvn eclipse:eclipse

If you can think of goals like atomic commands executing well known operations, on the other hand you can think of lifecycle phases like high-level abstract commands whose effects depend on the type of project they are being executed on. A Maven project build lifecycle is composed of a fixed number of lifecycle phases. Independently by the project type, a lifecycle phase is an ordered subset of the following steps (there are more steps than these but these are the most common):
validate, compile, test, package, integration-test, verify, install, deploy.
Every phase includes all the steps of the previous sequence up to the phase command itself, for example if we run the phase command:
mvn package
the Maven project will go through the validate, compile, test and finally the package steps.
As we said earlier, these phases are 'high level' commands because each phase is implemented by a sequence of (plugin) goals that depends on the type of project it's being invoked on. The package phase for a web application project will imply a different sequence of goals than a package phase on a simpler jar project but also different from a package on an ejb project and so on.
We don't need to know how "phase/project type" pairs are mapped onto sequences of plugin goals, that is Maven responsibility, that is where Maven comes into help.
Example of build lifecycle commands:
mvn install
You can find more info about the Maven "build lifecycle" here:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycl...

Multiple plugin and lifecycle commands can be mixed on a single command line, for example:
mvn clean dependency:copy-dependencies package
The clean command is a clean lifecycle command (there are three lifecycles in Maven, the clean, the default -usually called build- and the site lifecycle). Invoking the clean phase is slightly different than invoking the clean on the clean plugin like "clean:clean" because as we said there is a clean lifecycle that is composed of the following phases:
pre-clean, clean, post-clean.
Generally clean and clean:clean will have a similar effect but pre-clean and post-clean can be configured to execute extra tasks.

Maven configuration.
Maven and Maven projects configurations are defined by few xml files, the shared Maven settings.xml ($M2_HOME/conf/settings.xml), the user settings.xml (${user.dir}/.m2/settings.xml) where users can override portions of the shared Maven settings.xml or add their own properties definitions and the pom.xml files (every Maven project must have it's own pom.xml in its root directory).
Every pom.xml file contains all the informations about the project it defines, pom is the acronym of project object model.
For the sake of configuration reuse, a pom can inherit a configuration from a parent pom (using the lt;parent> tag) and/or can aggregate other poms (using the <modules> tag to declare the aggregated modules). Pom inheritance and aggregation are conceptually different forms of reuse, inheritance is reuse of configuration, aggregation is reuse by composition of modular configurations. In concrete the main difference is that invoking a command on a project whose pom aggregates multiple poms you are invoking that command on multiple projects while the same is not true with pom inheritance.
For both parent and aggregation projects the <packaging> tag that is child of <project> in the pom.xml must be set to type "pom":

<project>
   ...
   <packaging>pom</packaging>
   ...
</project>

For more informations about pom.xml you can give a look here:
http://maven.apache.org/pom.html
http://www.javaworld.com/javaworld/jw-05-2006/jw-0529-maven.html?page=1

If the pom is all about project configuration, the settings.xml files is mainly about the Maven configuration and architecture.
Maven can be used in different configurations/architecture, from a single user case where the user just uses maven on his local client to resolve dependencies and automate her own builds to complex multiple users scenarios where multiple users operating from different locations need to build and deploy the same centralized projects, sharing their own artifact one another, setting up a complex system of automated builds in an intranet environment.
Maven is not really a 'readymade' build system, it is more a kind of 'build systems' toolkit, around which you can implement your own build solutions.
Some possible Maven architectures...

Check here for more info about settings.xml:
http://maven.apache.org/settings.html
Transparent Proxies to connect a Maven instance to multiple Internal/Remote Repositories:
http://maven.apache.org/archiva/
http://proximity.abstracthorizon.org/
http://maven-proxy.codehaus.org/Configuration

Maven guides:
http://maven.apache.org/guides/
The Sonatype and the Mergere Maven 2 Book are great sources of informations:
http://www.sonatype.com/book/
http://www.devzuz.com/c/document_library/get_file?folderId=8&name=DLFE-5...
Another good source is the Maven Developer's Notebook from O'Reilly, even if it is not updated to Maven 2 it contains informations that you wouldn't find on the other sources I listed here:
http://www.oreilly.com/catalog/mavenadn/

Maven plugins:
http://maven.apache.org/plugins/