A wrapper class is simply a class used to store the collection of variables you need to render your iterable components. For example, let us say that we wanted a table with contacts and accounts, with the option to check the records (maybe for a mass action):

public class myController {
  public List<aTableRow> tableRows { get; set; }
  public class aTableRow {
    public Contact theContact { get; set; }
    public Account theAccount { get; set; }
    public Boolean isSelected { get; set; }
    public aTableRow(Contact c,Account a,Boolean b) {
      theContact = c;
      theAccount = a;
      isSelected = b;
    }
  }

  public myController() {
    tableRows = new List<aTableRow>();
    for(Contact c:[select id,firstname,lastname,account.id,account.name from contact limit 10]) {
      tableRows.add(new aTableRow(c,c.account,false));
    }
  }
}

The page's code would appear something like the following:

<apex:page controller="myController">
  <apex:form>
    <apex:pageBlock>
      <apex:pageBlockTable value="{!tableRows}" var="row">
        <apex:column><apex:inputCheckbox value="{!row.isSelected}"/></apex:column>
        <apex:column headerValue="Contact First Name"><apex:inputField value="{!row.theContact.firstname}"/></apex:column>
        <apex:column headerValue="Contact Last Name"><apex:inputField value="{!row.theContact.lastname}"/></apex:column>
        <apex:column headerValue="Account Name"><apex:inputField value="{!row.theAccount.name}"/></apex:column>
      </apex:pageBlockTable>
    </apex:pageBlock>
  </apex:form>
</apex:page>

Of course, you'd want to add commandButton or commandLink features to manipulate the records, but this is the proof of concept. Pagination would be accomplished not through a StandardSetController (because it is not a plain SObject), but would be accomplished through the use of one of several methods:

1) Store all the values in a huge list, and then use the parameters to limit the offset (first) and count (rows), and have commandLink or commandButton actions that increment or decrement first and/or rows to create pagination. The drawback here is a large view state will hinder page performance, and perhaps run into heap allocation errors (a Bad Thing).

2) The commandLink or commandButton that implements pagination performs a new query, discarding offset rows of data before adding count items to the list, and discards the rest of the query. The drawback to this design is that users must save between page navigations, and huge queries might take a while to complete.

3) Combine 1 and 2 above, perhaps by keeping a "dirty" list in the view state that stores records that were modified/selected/whatever. Your query will still take a finite amount of time, but a smaller view state will help your page's performance considerably.

The major consideration for pagination performance is determining what will be the larger bottleneck, namely memory or database queries. It may not actually matter which method you choose if your page will never be that big (for example, under 1000 records).