This is a great idea but I'd suggest a few things.
1 – after the demo, make the next section "What's different about Smalltalk?" rather than "What is Smalltalk?". Capture the minds that are familiar with some other well known tools. Cover the same ground, but slant it differently. The community might have ideas for highlights. I'd offer three. First, consistency – syntax is uniform, there are not multiple syntactic expressions for the same thing, and what you learn in one area applies in related areas (Algol 68 was the environment which pioneered this). Second: many concepts are usefully unpacked and available without un-necessary overheads. Both these elements can be exemplified through Collections which don't have to be ordered or arrayed if you don't want, for example; and you can elaborate String as a Collection (for example, use of "," to concatenate Collections). But be up-front that this consistency sometimes leads to counter-intuitive results, particularly in not using + for string concatenation and in some of the details of string vs character programming. Third, creating your own objects for concise and elegant programming (Algol-68 again). You might add that strong typing plus coercion is a preventative for all sorts of programming errors and horrid short cuts (A-68 has declarations and is more strongly typed than ST, but ST does keep track reasonably well as evidenced by "Object … does not understand …" errors).
2 - What took me longest to work out when I came to Smalltalk was the concept that objects communicate and are interrogated only through their methods: i.e. the internal state is not directly accessible (I came from an Algol-60-/Fortran background and ran a big Fortran program with lot of COMMON storage). Spend some time on this and its benefits.
3 – maybe include in the history the point in time, around 1990, when windowing OSs became available and Smalltalk-80 had to make the transition from its own pioneering GUI to interacting with the native one. For me this manifested itself in the arrival of X-Windows on Unix, and wholesale changes to the GUI classes which changed, therefore, also on other platforms. I was programming cross-platform for Unix and MacOS at the time, and this change caused lots of problems!
4 – coming back to VisualWorks after some years, relatively recently, it was great to discover the standard inclusion of HTTP access classes so no need for external sockets and TCP/IP RPC calls. Pulling information from web pages is easy!