1.  If I am using the ImageName method many times in different classes and VF pages, I thought it would be best to split this out into its own class so I dont have to keep writing the same thing each time (we have a lot of partner portal users, and no signs of slowing down any time soon).  In this case, I have tried to write the test method seperate, but with no success.  I can post the attempted test methods.  But I am not sure if  get/set makes the test code verbiage different.  Does it?

I've actually done this in a project. We have a set of PDFs that are rendered, but use some common logic, such as a logo file that is specified by the administrator, etc. You can use the class as an extension class, or you can make it a base class that the other portal controllers inherit from, depending on if the logic needs to communiate with the primary controller.

The first method looks like this:

public class SharedLogic {
  public SharedLogic( ApexPages.StandardController controller ) {
    // controller contains the page's record.
  }

  public String function1( ) {
    // return a string common to all pages
  }
}

While the second one looks like this:

public class BaseController {
  public BaseController( ) {
    // default initialization here
  }

  public String function1( ) {
    // return a string common to all classes
  }
}

public class SpecializedController extends BaseController {
  public SpecializedController( ) {
    super( ); // Call the base constructor; must be first function
    // do more initialization here
  }

  public String function2( ) {
    // This returns a string specific to this controller
  }

  // We can also call function1( ) from within this class.
}

2.  Would it be best common practice to initiate the set; to value even though it is default, or is that just a waste of time / code?

I would say that you should use custom accessors and mutators only if necessary. While the difference is minimal in terms of resources, I think that default setters and getters are preferable because they make the code easier to read. This is more a matter of preference, but do keep in mind that you have a limit to how much code you can use (3,000,000 characters total, and 1,000,000 per class), which seems like a lot, but using excessive code reduces the space you have left over for other functions. As a developer, you should strive for efficiency as much as possible.

3.  I have been writing all my classes thus far as this:  "public class getAllRecords", or "public with sharing class getLogoImage" and I have been writing all my methods the same (getImageName, or getClosedWon) etc.  If I start using get/set in my classes, how does that change what I have been doing?  Can I rewrite these so they are more effective?  (In other words can I graduate from sloppy to sophisticated ?)

The most important change would be your test methods; instead of calling a function, you access the member directly, which in turn calls the functions you've written. Using getX/setX functions instead of setters and getters likely increases the size of your code, although the difference is marginal. A major feature of using accessors and mutators is that it forces you to place the getters and setters next to each other, instead of potentially being spread throughout the class. Generally speaking, this feature means that your code's readability is improved, but excessively large getters and setters might actually decrease readability. If your function is larger than about 20 lines or so, consider using getX/setX functions instead, but do remember to keep them next to each other so they're easy to find.

If you have the time, consider using classes with inheritance or extension classes. They will make your code more manageable by localizing common features.

As some examples...

We have several pages that allow users to select from "sites", which will update the address fields for the record. The fields are dynamically mapped using a custom class that provides field mapping services for each of our custom objects. In this way, the address copying logic is reduced to a single instance instead of approximately 10 different classes, which provides a significant space savings. If any one page isn't working correctly, we can be certain that it is because our field mapping class is using the wrong fields, while if all pages are working incorrectly in regards to this feature, we can be certain that fixing the logic once will correct all of the pages.

We have several different types of "line items" that behave similarly to OpportunityLineItem, including using PricebookEntry Id values, discounts, and so on. Again, if a single type of object is behaving incorrectly, we know it is because of the field mapping, while if the logic affects all of our custom objects, we know which file to look at.

We also have various pages that have essentially the same function (editing a single line item record), but with slightly different logic in place for the various types of objects. In this case, we have a common class that contains the logic shared between all the different types of line items, plus some specialty classes that handle the distinct differences between the different types of line items. This particular use case shaved nearly 60kb of source code from our project.

In conclusion, I would say there are many types of tools available in Apex Code, and learning how to use each effectively is the key to elegant coding.