Factoring a PageObject on the page or an object in the page is a matter of re-factoring the test code routinely. Adam describes it in the screencast as an ongoing process. Start with the entire page and then break it down into parts of the page over time.
IMHO (I'm not the PageObjects guy) the Selenium project is caught between the world of proprietary test tool vendors and the software developer community. The proprietary test tool vendors (HP, IBM, SmartBears, MicroTrend, CA, etc.) tell testers not to learn how to code. Don't worry, they promise, we will take care of the complexity and give you a simple record/playback tool. The software developer community urges austerity to build reusable, easily maintained, pattern-based test objects.
Just as IDEs include Wizards to create new applications and classes, testers have tools that make it easy to start with record/playback and move into coding. There is a tipping point in tester productivity between record/playback and coding. My open source test tool, TestMaker, delays the tipping point a little by providing the TestMaker Object Designer (http://www.pushtotest.com/designer) for record/playback and then also runs test objects written in Java, Ruby, Python, and others once those make sense.
The problem for testers-that-want-to-code happens when they tip into object oriented coding patterns. Selenium does not have a official person or company to designate best practices. Oracle/Sun used to have this role for Java. It espoused EJB as the structure and patterns. HP and IBM have abdicated their responsibility to provide a code, community, and patterns around testing. That's a shame for testers who want to code.
The average tester that wants to code test objects has a variety of competing approaches: Selenium PageObjects, GEB, FIT, Fitness, etc. No wonder it is a confusing world for testers.